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This  is  the  first  edition  of  the  Amy 
HAREHAN  Comparability  Analysis  Methodology 
Guide.  It  was  cooplled  Jointly  under  the 
auspices  of  the  Ai^  Research  Institute  (ARI) 
and  the  Soldier  Support  Center-National  Capital 
Region  (SSC-NCR). 

Ihe  five  volumes  constitute  a  detailed 

specification  of  the  Army  HAREMAN  Methodology  as 
applied  to  major  materiel  systems.  The  Guide  is 

intended  to  provide  the  Ait^  with  a  basis  for 
competitive  HAREMAN  contracting,  conducting 
"in-house**  Army  HAREMAN  plications,  and 
providing  HAREMAN  training  for  Amy  personnel. 

In  the  foture,  many  of  you  may  becone  involved 
in  the  process  and/or  with  tiie  products  of  an 
Army  HAREMAN  Analysis.  These  volumes  have  been 
provided  as  an  aid  to  your  understanding  of  this 
analytical  tool. 

It  should  be  noted  that  the  HAREMAN 
procedures  described  herein  are  not  expected  to 
remain  forever  unchanged.  Rafoer,  it  is  desired 
that  HAREMAN  evolve  over  tixoe  to  better  meet  the 
Arxay's  changing  information  needs  on  newly 
emerging  systems.  You  are  invited  to 
particpte  in  this  evolutionary  process  by 
providing  your  comments  on,  and  recooisended 
improvements  to,  the  Methowlogy.  Sudi  ooaments 

concerning  the  Amy  HAREMAN  Guide  or  the  Army 
HAREMAN  Methodology  should  be  mailed  to: 

Coonander 

Soldier  Support  Center-National  Capital 

Region 

Am:  ATZI-IMS 

200  Stovall  St. 

Alexandria,  VA  22332-OAOO 

Additional  copies  of  the  HAREMAN 
Coo|>arability  Analysis  Methodology  Guide  will  be 
available  through  the  Defense  Tedmical 
Information  Center  (DTIC)  in  the  near  future. 
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To  the  Analyst 

Volumes  II  through  IV  are  intended  to  be  used  by 
individual  engineers  and  MPT  analysts  who  have  been 
tasked  with  conducting  the  HARDMAN  analysis.  These 
volumes  provide  detailed  descriptions  of  each  HARDMAN 
step,  substep  group,  and  substep.  The  analyst  is 
referred  to  the  preface  of  Volume  I  for  an  overall 
description  of  these  volumes  and  a  description  of  the 
organizational  format  of  each  step. 

The  analysis  flow  diagrams  depict,  at  a  high  level,  the 
general  flow  of  data  and  the  interrelationship  of  the 
individual  HARDMAN  substeps  (see  Volume  I,  Figures 
1.2-3  and  1.2-4).  The  descriptions  of  these  substeps 
provide  the  detailed  procedures,  algorithms,  and  rules 
required  to  co./luct  the  analysis  as  veil  as  examples  of 
pr^ucts  that  represent  the  results  of  the  analysis. 

In  essence,  these  flow  diagrams  and  substep 
descriptions  provide  the  analyst  with  guidance  on  how 
to  conduct  the  discrete  methodology  steps.  However, 
the  diagrams  and  descriptions  do  not  capture  much  of 
the  dynamics  of  a  study  application. 

Throughout  the  substep  descriptions,  the  analyst  is 
directed  to  interface  with  other  analysts  and  other 
data.  In  most  instances,  these  directions  are  not 
intended  to  reflect  formal,  one-time  meetings,  where 
the  output  of  one  substep  is  passed  on  as  input  to  the 
next.  Instead,  they  reflect  an  ongoing  give-and-take 
between  analysts. 

In  light  of  that,  it  cannot  be  overemphasized  to  the 
individual  analyst  that  the  HARDMAN  methodology  is  a 
highly  interactive  process  that  is,  by  necessity, 
conducted  by  a  multi-disciplinary  study  team  of 
engineers  and  analysts.  The  magnitude  and  complexity 
of  the  factors  that  are  necessary  to  capture  the  total 
operational  and  maintenance  requirements  of  a  weapon 
system  are  such  that  no  one  analyst  or  analysis  manager 
can  be  expected  to  have  a  total  grasp  of  the  whole. 

Each  analyst  must  contribute  not  just  the  formal  output 
of  his  or  her  discipline's  analytical  substeps  but  must 
participate  in  partnership  with  other  analysts  in 


system  definition.  This  is  especially  true  in  Step  1 
(Systems  Analysis),  where  the  decisions  about  the 
system's  scope  and  its  mission,  functional,  task,  and 
equipment  requirements  provide  the  basis  upon  which 
much  of  the  subsequent  analysis  is  conducted. 

Finally,  the  requirement  for  early  identification  and 
collection  of  data  must  be  stressed.  Results  obtained 
from  using  the  substep  procedures  described  in  this 
handbook  reflect  the  quality  and  completeness  of  the 
data  that  are  input.  Every  analyst  must  regard  as 
crucial  the  need  to  identify  data  at  the  earliest 
possible  time  and  to  see  to  it  that  data  requests  are 
pursued  in  a  timely  manner. 

Alternative  or  second-best  data  may  have  to  be  obtained 
if  it  appears  that  initial  data  requests  will  not  be 
received  in  time.  The  analyst  must  continuously  keep 
the  analysis  manager  informed  of  data  collection 
problems,  as  delays  will  have  a  negative  mpact  on 
study  milestones.  Accord;  gly,  the  analyst  should  give 
special  attention  to  the  guidance  presented  in  Appendix 
A  (Data  Operations)  of  Volume  V. 
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Systems  Analysis 

Overview  The  Systems  Analysis  step  of  the  HARDMAN 

methodology  systematically  examines 
identified  mission  needs  and  evaluates 
alternative  design  approaches  to  satisfying 
those  mission  reeds.  Mission  needs  establish 
the  requirement  for  a  new  or  improved  system 
design. 

First,  the  mission  need  is  identified,  and 
the  specific  system  functions  required  to 
meet  that  need  are  determined.  Next,  the 
analysis  determines  the  system  design  that 
will  enable  the  functional  requirements  to  be 
met.  System  design  includes  not  only 
equipment  configurations,  but  operational, 
organizational,  and  support  concepts  as  well. 

In  response  to  the  system  functional 
requirements,  at  least  three  system 
constructs  will  normally  be  identified. 

These  include  the  Predecessor  System  (the 
system  which  is  being  replaced,  if  one 
exists),  the  Baseline  Comparison  System 
(BCS),  and  the  Proposed  System  (which  may 
include  multiple  alternatives).  As 
illustrated  in  Table  1*1,  these  three 
constructs  are  distinguished  by  two 
functional  criteria:  functional  performance 
and  performance  standards. 


Table  T-t.  System  Constructs  vs.  Functional  Criteria 


SYSTEM  CONSTRUCTS 

FUNCTIONAL 

CRITERIA 

Does  the  System 
Construct  Perform 
All  New  System 
Functions? 

Does  the  System 
Construct  Meet  All 
New  System  Perfor¬ 
mance  Standards? 

Predecessor 

No 

No 

BCS 

Yes 

No 

Proposed 

Yes 

Yes 

step  1/Overview 


Because  the  Predecessor  System  meets  neither 
the  system  functional  requirements  nor 
performance  standards  for  the  new  system,  it 
is  being  replaced.  The  BCS  is  a  notional 
system  configuration  consisting  of  a 
composite  of  existing  fielded  systems, 
subsystems,  and  equipment.  It  is  assembled 
for  purposes  of  comparison  with  Proposed 
System  designs. 

BCS  component  selections  are  made  in  order  to 
satisfy  all  new  system  functional 
requirements.  However,  the  BCS  may  not 
fulfill  all  new  system  performance  standards. 
Finally,  by  definition,  the  Proposed  System 
will  satisfy  all  new  system  functional 
requirements  and  performance  standards. 

Systems  Analysis  may  be  performed  at 
different  phases  of  a  system  acquisition. 
During  later  phases,  the  Proposed  System 
design  may  be  well  defined.  If  performed 
early  in  an  acquisition  at  a  time  when 
little,  if  any,  new  design  information  is 
available,  the  Proposed  System  design  is  a 
projection  based  on  engineering  judgment.  In 
this  case,  the  analyst  will  use  the  BCS 
design  to  project  an  evolutionary  design 
improvement,  one  that  incorporates  low-risk 
technological  advances. 

The  HARDMAN  Systems  Analysis  step,  like  the 
rest  of  the  methodology,  is  necessarily 
data-intensive.  Data  timeliness, 
completeness,  and  accuracy  are  prime  concerns 
throughout  Systems  Analysis.  Despite  the 
fact  that  Systems  Analysis  substeps  can 
proceed  independently  in  the  early  stages  of 
a  HARDMAN  application,  they  become 
increasingly  interdependent  (see  Figure  1-1). 

In  most  situations,  delays  in  data  collection 
actions  pose  the  greatest  risk  to  the  smooth 
progress  of  each  analysis  step  and, 
ultimately,  to  the  entire  analysis.  Planning 
and  coordinating  data  collection  is  an 


Figure  1-1.  Relationship  of  System  Analysis  to  Other  HARDMAN  Steps. 


Step  1 /Overview 


immediate  concern  of  any  HARDMAN  analysis. 
Specific  data  collection  requirements  are 
discussed  in  each  Systems  Analysis  substep. 


Objectives  The  eight  major  objectives  of  the  HARDMAN 

System  Analysis  are: 

•  To  identify  the  mission  needs  which 
require  the  development  of  the 

new  system 

•  To  determine  the  major  system  func¬ 
tions  required  to  accomplish  the 
mission  needs 

•  To  identify  the  system  being  re¬ 
placed,  if  any 

(Meeting  the  above  objectives  results  in 

establishment  of  the  Predecessor  System.) 

•  To  identify  the  Proposed  System,  in¬ 
cluding  actual  or  projected  new  system 
design  concepts  and  equipment  configura¬ 
tions  as  well  as  potential  alternative 
designs  which  meet  all  new  system ’func¬ 
tional  requirements  and  performance 
standards 

•  To  identify  the  Baseline  Comparison 
System  (BCS)  for  the  purpose  of  compari¬ 
son  with  the  Proposed  System;  the  BCS 

is  a  notional  system  configuration  which 
is  a  composite  of  existing,  fielded 
systems,  subsystems,  and  equipment;  it 
must  perform  all  new  system  functions 
but  may  not  meet  new  system  performance 
standards 

•  To  identify  the  design  d.fferences 
between  the  BCS  and  the  Proposed  System 
and  to  assess  the  impacts  of  the  design 
differences  on  BCS  MPT-related  parameters 


Step  1 /Overview 


Interrelationships 


•  To  determine  the  reliability  and  maintain¬ 
ability  parameters  for  the  Predecessor, 
BCS,  and  Proposed  Systems 

•  To  determine  the  generic  operator  and 
maintainer  tasks 


Figure  1-2  presents  an  overview  of  the 
relationship  between  Systems  Analysis  and  the 
other  HARDMAN  steps.  Data  collection 
requirements  affect  all  HARDMAN  steps  but  are 
not  shown  in  Figure  1-1.  Collection  of 
program  background  information,  including 
mission  and  functional  requirements 
information,  must  be  completed  in  order  to 
perform  Substeps  lA  (Mission  Analysis)  and  IB 
(Functional  Requirements  Analysis). 

Data  collection  begins  for  the  remaining 
HARDMAN  steps  once  the  Predecessor,  BCS,  and 
Proposed  System  designs  have  been  identified 
in  Substep  1C  (Equipment  Comparability 
Analysis).  To  maximize  efficiency  and 
consistency,  data  collection  efforts  for  all 
HARDMAN  steps  must  be  carefully  coordinated. 


As  illustrated  in  Figure  1-2,  the 
comparability  analysis  performed  in  Step  1  is 
essential  for  projecting  Proposed  System 
manpower  and  training  requirements.  As  such, 
design  differences  and  their  impacts  are 
input  to  Steps  2  (Manpower  Requirements 
Analysis)  and  3  (Training  Resource 
Requirements  Analysis),  respectively. 

Reliability  and  maintainability  analysis 
provides  the  basis  for  aggregating 
maintenance  workload  requirements  as  a 
preliminary  step  to  computing  manpower. 
Generic  task  identification  contributes  to 
manpower  and  training  resource  requirements 
analyses.  Feedback  to  Systems  Analysis 
occurs  during  examination  of  alternative 
system  design  within  Step  6  (Tradeoff 
Analysis) . 
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Assumptions/  The  following  assumptions  and  constraints 

Constraints  must  be  kept  in  mind  when  conducting  Step  1 

of  a  HARDMAN  analysis: 


•  All  results  of  the  System  Analysis  are 
based  on  the  best  available  data. 
Incomplete  or  inaccurate  input  data  may 
produce  misleading  results  and  invali¬ 
date  conclusions. 

•  Information  on  Proposed  System  alterna¬ 
tives  may  be  sensitive  among  competi¬ 
tors  and,  for  that  reison,  difficult 

to  obtain. 

•  When  Proposed  System  data  are  not 
available  from  a  prime  contractor  or 
government  srirce,  they  will  be  esti¬ 
mated  on  the  jasis  of  BCS  data. 

•  The  projected  design  of  the  Proposed 
System  will  be  determined  on  the  basis 
of  the  BCS  system  construct  and  will 
incorporate  low-risk  technological 
improvements.  Design  differences 
between  the  BCS  and  the  Proposed  System 
design  are  then  documented. 

•  Impacts  of  BCS/Proposed  System  design 
differences  are  estimated.  Design 
difference  impacts  are  used  to  pertur- 
bate  BCS  parameters  (such  as  R/M  values) 
to  derive  Proposed  System  parameter 
estimates. 

•  Design  differences  must  be  updated  and 
revised  as  actual  Proposed  System 
design  data  become  available. 

•  When  Proposed  System  data  are 
available,  BCS  data  will  not  be 
perturbed  but  will  serve  only  as  a 
basis  of  comparison. 


step  1 /Overview 


Comparability  analysis  is  the  primary 
technique  for  performing  a  HARDMAN  Systems 
Analysis.  Within  this  step,  comparability 
analysis  consists  of  systematically  comparing 
the  BCS  and  Proposed  System  constructs. 

When  the  Proposed  System  is  not  completely 
defined,  BCS  performance  capabilities  are 
compared  to  Proposed  System  performance 
requirements.  Low-risk  technological 
advances  are  incorporated  into  BCS  components 
to  derive  a  projected  Proposed  System  design. 

Comparability  analysis  is  the  means  by  which 
BCS/Proposed  System  design  differences  are 
identified  and  evaluated.  Due  to  its  impact 
on  subsequent  HARDMAN  analysis  steps,  all 
design  differences  which  could  impact  system 
MPT  resource  requirements  must  be  identified. 

Due  to  the  evolutionary  nature  of  system 
development,  HARDMAN  comparability  analysis 
is  an  ongoing  process.  The  evolving  Proposed 
System  design  must  be  continually  compared  to 
the  BCS,  and  the  design  differences  must  be 
updated  accordingly. 


Comparability 

Analysis 
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Substep  Group  1A _ 

Mission  Anaiysis 

Purpose  A  HARDMAN  analysis  estimates  the  manpower, 

personnel,  and  training  (MPT)  requirements 
for  materiel  systems,  typically  in  the  early 
phases  of  the  Army’s  Life  Cycle  System 
Management  Model  (LCSMM).  MPT  requirements 
estimates  are  produced  for  operators  and 
maintainers  of  the  new  system.  The  estimates 
must  be  uniquely  associated  with  a  specified 
set  of  system  missions  on  the  battlefield 
under  the  environmental  conditions  likely  to 
be  found  there. 

The  format  for  military  operations  orders 
defines  "mission”  as  a  clear,  concise 
statement  of  a  task,  or  tasks,  to  be 
accomplished  by  a  command.  Task  purpose  is 
also  stated.  By  implication,  missions  may  be 
assigned  to  any  element  of  the  command. 

As  used  in  HARDMAN,  a  "system”  is  a 
combination  of  people,  equipment,  and 
information  which,  when  taken  as  a  whole,  is 
capable  of  performing  a  required  mission. 
Thus,  missions  assigned  to  a  specific  system 
support  accomplishment  of  the  overall  mission 
assigned  to  the  command,  or  unit,  to  which 
the  system  belongs. 

• 

As  with  general  missions  assigned  to  units, 
the  particular  characteristics  of  system 
missions  vary  with  the  unit’s/system’s 
mission  area.  Mission  areas  are  broad 
subdivisions  of  the  Army's  overall  mission, 
which  is  to  prepare  for,  engage  in,  and  win 
land  wars. 

TRADOC  Regulation  11-8  (Combat  Development 
Studies)  defines  twelve  mission  areas  and 
assigns  each  to  a  proponent  TRADCX:  school  or 
center.  Boundaries  for  some  mission  areas 
are  clear,  as  the  mission  area  is  congruent 
with  the  types  of  units,  forces,  and 
personnel  for  which  the  proponent  is 
responsible. 


Examples  are  Armor  (Close  Combat--Heavy 
Mission  Area)  and  Air  Defense  (Air  Defense 
Mission  Area).  In  other  mission  areas,  such 
as  cokTimand  and  control,  communications,  and 
combat  service  support,  the  boundaries  are 
less  clear.  There,  the  proponent's 
responsibilities  are  an  integral  part,  of  all 
mission  areas. 

A  HARDMAN  Mission  Analysis  has  two 
objectives.  The  first  is  to  identify  the 
mission  area(s)  supported  by  the  system  under 
study.  This  serves  to  place  the  system 
within  a  well-defined  context. 

Because  MPT  information  is  also  sorted  by 
proponent  and  mission  areas,  establishing  a 
well-defined  mission  area  context  for  the 
system  at  the  outset  of  a  HARDMAN  application 
narrows  requirements  for  data  collection. 
Further,  some  HARDMAN  procedures,  such  as 
Substep  Group  2A  (MOS/Grade  Determination), 
draw  heavily  on  the  mission  area  context. 

The  second  purpose  of  Mission  Analysis  is  to 
derive  detailed  system  usage/activity  rates 
from  the  general  information  provided  in  the 
system's  statement  of  missions  and  expected 
environment.  Although  estimates  of  operator 
and  maintainer  MPT  requirements  are  derived 
differently,  both  depend  on  detailed, 
integrated,  and  logically  consistent  system 
usage/activity  data.  These  data  are  the 
quantifiable  result  of  the  system's 
performance  in  response  to  its  mission 
requirements  under  the  prescribed  conditions. 

Often,  system  mission  requirements  and/or 
environmental  conditions  are  stated  at  a  very 
general  level.  Either  no  usage/activity  data 
exist,  or,  if  specified,  they  may  not  be 
integrated  or  may  lack  sufficient  detail  to 
derive  accurate  rates. 
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Various  Sourcts,  MAA, 
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Substep  1.1/Overview 

Identify  General  Mission  Requirements 


Objectives 


Input 

* 


Products 


) 


Logic 


The  purpose  of  this  substep  is  to  place  the 
system  being  studied  in  the  context  of  one  or 
more  standard  Army  mission  areas.  Because 
manpower,  personnel,  and  training  (MPT) 
information  is  also  sorted  by  mission  areas, 
establishing  a  well-defined  mission  area 
context  for  the  system  at  the  outset  of  a 
HARDMAN  application  narrows  requirements  for 
data  collection.  Further,  identification  of 
the  context  is  a  prerequisite  for  performing 
some  HARDMAN  substeps. 


No  other  HARDMAN  substeps  provide  input  to 
this  substep.  Inputs  from  other  sources 
include  the  Mission  Area  Analysis  (MAA)  for 
the  mission  area  of  the  system  under 
analysis;  the  system's  Organizational  and 
Operational  (OfcO)  Plan,  if  available;  and 
general  sources  of  doctrinal  information  such 
as  the  how-to-fight  field  manual  (FM)  series 
for  the  system's  mission  area. 


This  substep  produces  two  cutputs.  The  first 
is  a  list  of  general  mission  requirements 
which  apply  to  the  system,  based  on  placing 
the  system  in  one  or  more  mission  areas.  The 
second  output  describes  specific  system 
missions,  to  the  extent  that  they  can  be 
determined  from  available  documentation. 


The  process  of  identifying  a  system's  general 
mission  requirements  is  a  judgmental  one.  It 
relies  heavily  on  the  analyst's  skill  and 
knowledge  of  the  system's  mission 
requirements  and  expected  environment. 

Figure  1.1-1  depicts  the  logic  flow  for 
determining  general  mission  requirements. 
This  substep  contains  one  action  step. 


A/Substep  1.1 


Action  Step 

Requirements 

In  this  action  step,  the  analyst  determines 
the  mission  area(s)  to  which  the  system  under 
study  belongs  and  determines  specific 
missions  that  may  be  assigned  to  that  system. 

Objective 

The  objective  is  to  determine  the  mission 
area(s)  and  specific  missions  that  may  be 
assigned  to  the  system  under  analysis. 

Procedures 

1.  Using  available  documentation,  the 
analyst  determines  the  mission  area  or  areas 
to  which  the  system  under  analysis  belongs. 

Table  1,1-1  provides  a  list  of  the  twelve 
mission  areas  defined  in  TRADOC  Regulation 

11-8  (Combat  Development  Studies).  Also 
shown  in  Table  1.1-1  is  the  TRADOC  school  or 
center  responsible  for  efforts  supporting  the 
mission  area.  The  schools  or  centers  are 
referred  to  as  "proponents." 

Table  1,1-1,  Mission  Areas 

Mission  Area  Description  Proponent 

Close  Combat,  Efforts  directly  related  to  the  Infantry 

Light  generation  of  combat  power  by  light  School 

forces  for  target  servicing  enemy 
forces  within  line  of  sight  of 
primary  weapon  systems.  Included 
are  programs  for  combat  mobility, 
mortars,  and  anti -armor  capabi¬ 
lity. 

Efforts  directly  related  to  gen¬ 
eration  of  combat  power  by  heavy 
forces  for  the  purpose  of  target 
servicing  enemy  forces  within 
line  of  sight  of  primary  weapon 


Close  Combat, 
Heavy 


Armor 

School 


A/Substep  1.1 


Table  1.1-1.  Mission  Areas  [con’*.) 


Mission  Area 


Description 


Fire 

Support 


Air 

Defense 


Communica¬ 

tions 


systems.  Included  are  programs 
for  combat  mobility,  mortars, 
and  anti-armor  capability. 

Efforts  directly  related  to  gen¬ 
eration  of  indirect  fire  combat 
power  for  destroying,  disrupting, 
suppressing,  or  neutralizing 
enemy  forces.  This  encompasses 
target  servicing  of  enemy  forces 
engaged  in  the  direct  fire  battle, 
counterfire  of  enemy  indirect  fire 
systems,  and  the  interdiction  of 

all  other  forces  not  involved  in 
direct  fire  battle.  Included  are 
programs  for  field  artillery  wea¬ 
pons  and  munitions  and  target 
acquisition  means  considered  inte¬ 
gral  to  the  fire  support  system.  Of¬ 
fensive  chemical  and  nuclear  fire 
support  and  the  lethal  attack  of 
emitters  are  integral  to  this 
mission  area. 

Efforts  directly  related  to  de¬ 
stroying,  nullifying,  or  reducing 
effectiveness  of  enemy  air- 
breathing  and  tactical  ballistic 
systems.  Included  are  friendly 
target  acquisition  means  consid¬ 
ered  integral  to  the  air  defense 
system  as  well  as  other  air 
defense  sensors  and  related 
command  and  control. 

Efforts  related  to  the  capa¬ 
bility  to  provide  accurate, 
timely  communications  among  tac¬ 
tical  units  and  between  tactical 
and  strategic  networks.  Included 
is  the  capability  to  communicate 
in  an  enemy- induced  EW  environment. 


Proponent 


Field 

Artillery 

School 


Air 

Defense 

School 


Signal 

School 


A/Substep  1.1 


Table  1.1-1.  Mission  Areas  [con't] 


Mission  Area 


Descript  ion 


Command 

and 

Control 


Intelligence 

and 

Electronic 

Warfare 


Combat 
Support, 
Engineering 
and  Mine 
Warfare 


Efforts  related  to  capabilities 
required  to  analyze  information, 
assess  situation,  and  direct  and 
control  tactical  units  during  com¬ 
bat  operations.  Includes  tactical 
information  systems  and  systems 
for  controlling  and  releasing 
nuclear  weapons. 

Efforts  related  to  the  capability 
to  determine  movement,  character, 
disposition,  type,  and  intention 
of  hostile  units  to  support  battle¬ 
field  management  and  acquisition 
of  targets  for  combat  actions. 
Includes  surveillance  in  support 
of  command  and  control  and  means 
to  correlate,  integr^'te,  and  fuse 
this  information  wit.i  other  sensor 
systems  into  intelligence.  Also 
includes  the  capeblity  to  detect, 
identify,  locate,  report,  disrupt, 
deceive,  and  exploit  hostile 
electromagnetic  systems.  Excludes 
target  acquisition  capabilities 
integral  to  a  class  of  firepower 
means. 

Efforts  related  to  combat  engineer 
operations  and  mine/countermine 
warfare.  Encompasses  position  forti¬ 
fication  to  enhance  survivability, 
emplacement  of  barriers  and  obstacles 
to  impede  enemy  movement,  and  breach¬ 
ing  of  natural  and  man-made  obstacles 
to  improve  friendly  force  movement. 
Included  are  artillery-delivered 
mines,  engineering  support  in  con 
struct  ion  and  road  maintenance, 
bridging,  electrical  power  support, 
and  mine  clearing. 


Proponent 


Combined 

Arms 

Center 

Development 

Activity 


Intelligence 

School 


Engineer 

School 
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Table  1.1-1.  Mission  Areas  [coni.] 


Mission  Area  Description  Proponent 


Combat  Efforts  directly  related  to  capa-  .  Logistics 

Service  bilities  providing  land  tactical  Center 

Support  commanders  with  supply,  maintenance,  assisted  by 

services,  energy,  medical,  and  per-  Soldier 
sonnel  administration  support.  Support 

Encompasses  essential  battle  support  Center 
to  committed  forces,  ordinary  and 
extraordinary  measures  taken  to 
reconstitute  the  force  continuously, 
and  rapid  movement  of  troops  and  sup¬ 
plies  to  concentrate  combat  power  at 
critical  times  and  places.  Includes 
only  those  transportation  system 
capabilities  controlled  by  senior 
land  tactical  commanders. 

NBC  Capabilities  required  to  support  Chemical 

combat  efforts  operating  in  a  nu-  School 
clear,  bacteriological,  or  chemical 
environment  and  offensive  (less  fire 
support)  chemical  warfare. 


Aviation  Capabilities  provided  to  the  land  Aviation 

tactical  commander  by  fixed  and  School 

wing  aircraft. 

Special  Capabilities  required  to  conduct  Special 

Operations  unconventional  warfare,  participate  Warfare 

in  foreign  internal  defense  matters.  Center 
strike  operations,  reconnaissance, 
civil  affairs,  and  psychological 
operations  in  support  of  national 


authorities  and/or  the  land  tactical 
commander. 
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2a.  The  analyst  subdivides  the  mission  area 
into  logical  categories  to  determine  the 
specific  missions  that  may  be  assigned  to  the 
system  under  analysis.  A  mission  area  may  be 
subdivided  according  to  the  type  of 
activities  that  the  forces  and  systems 
contained  within  mission  areas  are  expected 
to  accomplish  on  the  battlefield.  Current 
MAA  documentation  refers  to  these  activities 
as  "tasks." 

In  FARDMAN,  "task"  is  defined  as  an  action 
involving  human  performance  below  the  level 
of  a  system.  The  analyst  is  cautioned  not  to 
confuse  these  two  meanings  of  the  term. 

Table  1.1-2  provides  examples  of  battlefield 
"tasks. " 


Table  1.1-2.  Battlefield  Tasks 

Mission  Area  :  Fire  Support 

Tasks  :  Control  Battle 

Maneuver 
Acquire  Target 
Receive  Targeting 
Information 
Process  Target 
Attack  Target 
Assess  Target  Attack 


As  described  above,  these  tasks  are 
"functional"  in  nature.  In  other  words,  they 
refer  to  the  functions  that  must  occur  within 
the  mission  area. 

2b.  Another  way  to  subdivide  the  mission 
area  is  to  refer  to  the  outcomes  of  the 
process.  These  outcomes  are  often  found  in 
doctrinal  literature,  such  as  the 
how-to-fight  field  manual  series  which 
pertains  to  the  mission  area. 
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Example 


After  consulting  FM  6-20  (Fire  Support  in 
Combined  Arms  Operations),  the  analyst 
determines  that  Fire  Support  is  expected  to 
deliver  four  types  of  fire:  Close  Support 
Fire,  Counterfire,  Interdiction,  and  Other, 
such  as  suppression  of  enemy  air  defense 
(SEAD).  The  analyst  would  also  consider  this 
outcome  or  product-oriented  classification  in 
determining  the  specific  missions  appropriate 
to  the  mission  area  that  may  be  assigned  to 
the  system  under  analysis. 


Substep  1.2/Overview 

Identify  Detailed  Mission  Requirements 


Objectives 


Input 


This  substep  derives  detailed  usage  or 
activity  data  which  corresponds  to  the  system 
under  analysis  and  to  the  subsystems, 
components,  and  assemblies  which  comprise  it. 
A  detailed  statement  of  the  usage/activity 
required  of  a  system  under  a  combat  scenario 
may  not  be  available  early  in  a  system's 
development,  when  HARDMAN  is  typically 
applied. 

On  the  other  hand,  several  distinct, 
non-integrated,  and  mutually  exclusive 
specifications  of  required  activity  may 
exist.  This  depends  on  the  complexity  of  the 
system,  the  number  of  battlefield  functions 
it  is  expected  to  perform,  the  number  of 
different  operating  environments,  and  the 
length  of  time  it  is  expected  to  operate. 

The  objectives  of  this  substep  are  (1)  to 
develop  the  required  usage/activity 
information  when  none  or  little  is  available 
and  (2)  to  integrate  and  normalize  the 
available  information  as  required. 


Input  to  this  substep  from  other  HARDMAN 
substeps  includes  the  general  mission  context 
of  the  system  under  analysis  and  the  specific 
missions  assigned  to  it  from  Substep  1.1 
(Identify  General  Mission  Requirements). 
Substep  1.3  (Determine  Functional 
Requirements)  contributes  system  functions 
and  functional  requirements. 

Other  input  includes  the  Mission  Area 
Analysis  (MAA)  for  the  mission  area  of  the 
system  under  analysis;  the  system's 
Operational  and  Organizational  (O&O)  Plan, 
including  the  Mission  Profile/Operational 
Mode  Summary  if  available;  and  general 
sources  of  doctrinal  information,  such  as  the 
how-to-fight  field  manual  series  for  the 
system's  mission  area. 


Substep  1 .2/Overview 


Products 


Logic 


The  detailed  mission  requirements 
identification  process  produces  the 
usage/activity  rate  for  each  system.  This 
rate  is  the  quantification  of  system  usage  in 
miles  driven,  rounds  fired,  hours  operated, 
etc.,  required  over  time  to  accomplish  the 
system's  assigned  missions. 


This  substep  is  performed  because  detailed 
system  usage  data  required  for  other  HARDMAN 
steps  may  not  be  available.  If  the  data  are 
available,  however,  detailed  development  of 
system  usage/activity  data  is  abbreviated. 

Analysis  is  limited  to  insuring  that  the  data 
are,  in  fact,  suitable  to  input  to  other 
HARDMAN  substeps.  At  the  other  extreme,  no 
detailed,  system-specific  usage/activity  data 
may  be  available  to  the  analyst.  In  that 
case,  the  analyst  must  develop  the  data  "from 
scratch. " 

Having  no  data  at  all  is  particularly 
undesirable,  since  it  places  the  HARDMAN 
analyst  in  the  position  of  developing  data 
which  are  really  in  the  province  of  combat 
doctrine.  While  the  HARDMAN  methodology  must 
be  sensitive  to  doctrine,  doctrinal 
development  is  not  part  of  the  methodology. 

The  most  likely  situation  is  that  some 
detailed  usage/activity  data  are  available. 
The  analyst  clarifies,  rationalizes,  and 
interprets  available  data  to  derive  a 
complete  set  of  detailed  system 
usage/activity  data.  This  derivation  process 
is  definitely  judgmental.  It  relies  heavily 
on  analyst  skill  and  knowledge  of  the 
system's  mission  requirements  and  expected 
environmental  conditions. 

Figure  1.2-1  depicts  the  logic  flow  for 
determining  detailed  mission  requirements. 

As  shown  in  the  figure,  this  substep 
comprises  four  action  steps. 


A/Substep  1.2 


Action  Steps 

Action  Step  1: 

Requirements 

Objective 


Procedures 


Array  System  Functions  Over  Time 


System  functions  were  identified  in  Substep 
1.3  (Determine  Functional  Requirements).  In 
this  action  step,  the  analyst  establishes  the 
temporal  relationships  between  and  among 
system  functions. 


Given  a  particular  group  of  functions,  the 
objective  of  this  substep  is  to  determine 
which  can  be  done  sequentially  and  which 
simultaneously.  On  the  other  hand,  to 
complete  some  missions,  sequential  or 
simultaneous  performance  is  required  rather 
than  left  to  operator  discretion. 
Establishing  the  temporal  relationships,  or 
timelines,  identifies  these  situations  for 
the  analyst. 


1.  Substep  1.3  (Determine  Functional 
Requirements)  identified  the  functions 
required  to  perform  the  system's  assigned 
missions.  Such  functions  may  be  required  to 
support  several  missions.  The  analyst 
establishes  which  are  required  for  a 
particular  mission. 

2.  For  a  particular  mission,  the  analyst 
examines  system  functions  to  establish  two 
categories:  sequential  and  simultaneous. 
Doctrinal  field  manuals,  particularly  the 
how-to-fight  series,  and  technical  manuals 
for  existing  systems  within  the  mission  area 
are  principal  sources  of  timeline 
relationships  of  system  functions. 
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3.  The  analyst  establishes  the  temporal 
relationship  among  the  functions  by  answering 
the  following  questions: 


•  Given  that  all  system  functions  are 
essential  to  successful  accomplishment  of 
battlefield  missions,  are  all  functions 
equally  possible  at  any  particular  point 
in  time? 

•  Are  functions  mutually  exclusive? 

•  Is  the  arrangement  of  functions 
"permissive"?  In  other  words,  can  system 
operators  vary  the  relationship  among 
functions  according  to  conditions 
prevailing  on  the  battlefield? 

•  Is  the  arrangement  of  functions 
"prescribed,"  i.e.,  fixed  either  by 
doctrine  or  the  constraints  of  the 
prevailing  technology? 


Example 


A  tank  may  shoot  and  move  simultaneously  if 
it  has  a  gun  stabilization  system.  Shooting 
on  the  move  is  a  capability  required  of 
current  tanks.  A  howitzer,  on  the  other 
hand,  must  be  stationary  when  firing. 
Therefore,  shooting  and  moving  are  mutually 
exclusive  functions  for  the  howitzer. 


Both  the  tank  and  the  howitzer  are  required 
by  doctrine  to  communicate  continuously. 
Consequently,  communications  is  a 
simultaneous  function  in  both  systems. 

Figure  1.2-2  depicts  the  functional  timelines 
of  a  tank  and  of  a  howitzer. 
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Action  Step  2:  Identify  and  Sequence  Mission  Events  Required  By  Each  Function 

Requirements  Mission  events  are  the  separate,  discrete 

actions  which  comprise  a  function.  The 
analyst  must  identify  the  mission  events 
which  apply  to  the  functions  of  concern. 
Following  the  logic  of  the  previous* act  ion 
step,  the  analyst  must  also  establish  the 
temporal  relationship,  or  timelines,  among 
the  mission  events. 


Objective  The  purpose  of  this  action  step  is  to 

identify  and  place  in  sequence  the  mission 
events  that  comprise  each  function. 


Procedures  1.  Mission  events  embody  functions  at  a 

lower  level  of  detail.  Which  mission  events 
comprise  a  function  can  be  determined  by  the 
analyst  through  research  and  through 
professional  judgment,  both  on  the  part  of 
the  analyst  and  any  subject-matter  experts 
consulted.  The  analyst  divides  the  function 
into  discrete  actions  which  fully  describe 
the  system's  performance  of  the  function. 

2.  Mission  events  can  be  found  in  many  of 
the  same  sources  as  the  required  system 
functions.  These  sources  include  doctrinal 
field  manuals,  especially  the  how-to-fight 
series  for  the  system's  mission  area; 
operator  manuals;  soldier's  and  trainer's 
guides  for  the  Predecessor  System,  if  one 
exists;  and  employment  or  operational 
concepts  contained  in  the  new  system's 
Operational  and  Organizational  (OfcO)  Plan. 

3.  Once  mission  events  are  identified,  the 
analyst  uses  the  same  logic  as  Action  Step  1 
to  establish  a  prescribed  sequence  of  mission 
events.  Because  mission  events  outnumber 
functions,  mission  events  can  be  combined  in 
more  ways.  Instead  of  a  prescribed  or 
definite  sequence  of  mission  events,  several 
sequences  may  be  desired  under  different 
employment  conditions. 
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Examples 
Example  1 


Example  2 


The  sequence  or  set  of  sequences  finally 
decided  on  usually  depends  on  decision  rules 
which  are  either  implicit  or  explicit  in  the 
governing  employment  of  the  system.  The 
analyst  must  uncover  these  rules,  make  them 
explicit,  and  use  them  to  construct  mission 
event  sequences,  or  timelines,  which  are  both 
acceptable  to  Army  users  and  sufficient  to 
support  subsequent  HARDMAN  steps. 


For  the  howitzer  of  the  previous  example,  the 
analyst  identifies  the  following  mission 
events  for  each  function: 


Funct ion 
Communicate 
Shoot 
Move 


Mission  Event 

Communicate 

Fire  Mission 

Disemplace 

Transit 

Emplace 


Figure  1.2-3  depicts  the  sequence  of  these 
mission  events. 


Situation.  A  ground  missile  launcher  has  two 
missiles.  The  system  will  operate  by 
shuttling  between  a  launch  area,  a  hiding 
area,  and  a  missile  resupply  point.  A 
mission  cycle  begins  when  the  system  leaves 
the  resupply  point  and  ends  when,  having 
fired  both  missiles,  the  system  returns  to 
the  resupply  point.  The  system  may  fire  both 
missiles  at  one  launch  area,  fire  and  move  to 
a  hiding  area,  or  move  to  another  lauch  area 
directly.  The  analyst  must  construct  a 
sequence  of  mission  events  to  cover  the 
possible  movements  of  the  missile  launcher. 
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Action  Step  3: 

Requirements 


Oblective 

Procedures 


Results.  The  analyst  makes  one  simplifying 
assumption  and  confirms  it  with 
subject-matter  experts.  The  assumption  is 
that  if  the  system  enters  a  launch  area,  it 
will  fire  one  of  its  missiles.  Assuming 
this,  the  analyst  can  construct  a  mission 
event  sequence  diagram  (see  Figure  1.2-4). 


Determine  System  Operating  Metrics 


System  usage  and  activity  can  be  accounted 
for  by  different  units  of  measure,  or 
metrics.  One  or  several  metrics  may  apply  to 
the  operations  of  a  single  system.  Regarding 
the  system  being  studied,  the  analyst  must 
identify  which  metrics  apply  to  the  system  as 
a  whole  and  which  apply  to  its  constituent 
elements. 


The  purpose  of  this  step  is  to  identify  the 
operating  metrics  that  best  characterize  the 
operations  of  the  system  under  analysis. 


1.  For  the  system  being  studied,  the  analyst 
determines  what  units  of  measure  are  relevant 
to  its  operational  requirements.  Military 
Standard  1388-2A  (Logistic  Support  Analysis 
Record  Data  Elements  and  Requirements) 
provides  a  list  of  operating  metrics  under 
the  term  "Measurement  Base."  Table  1.2-1 
lists  these  metrics. 
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Table  1.2-1.  System  Operating  Metrics 


Time- 

Distance- 

Event- 

Related 

Related 

Related 

Minutes 

Miles 

Cycles. 

Hours 

Kilometers 

Starts 

Days 

Landings 

Months 

Years 

Flight  Hours 
Operating 

Hours 

Underway/ 

Steaming 

Hours 

Rounds 

2.  If  available,  the  system's  Mission 
Profile/Operational  Mode  Summary  may  provide 
essential  but  not  necessarily  all  system 
operating  metrics. 


3.  Operations  of  mult iple-f unction  systems 
are  typically  described  by  more  than  one 
operating  metric.  These  metrics  apply  to 
different  system  elements. 

If  the  relationship  among  the  metrics  is 
constant,  it  may  be  useful  for  the  analyst  to 
normalize  the  different  metrics.  To 
normalize,  the  analyst  obtains  a  factor  for 
converting  one  metric  to  another.  However, 
if  the  relationsiiip  is  not  constant,  it  is 
advisable  to  leave  the  metrics  distinct. 


ExamplM 


Example  1 


Table  1.2-2  provides  an  example  of  a  Mission 
Profile/Operational  Mode  Summary  (MP/OMS)  for 
a  hypothetical  system. 
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Table  1.2-2.  MP/OMS  Example 


Mission 

Essential 

Function 

Mission  Profile 

Annual 

Usage 

Static 

Dynamic 

Ground 

Support 

Fire  Control 

14  hrs 

24  hrs 

0  hrs 

3,060  hrs 

Shoot 

240  rds 

160  rds 

360  rds 

46,000  rds 

Mobility 

12  mi 

30  mi 

30  mi 

3,300  mi 

Expected 

Percentage 

75 

20 

5 

N/A 

Climatic  Design  Types 

%  Fleet 

(AR  70-38) 

Hot 

20 

Basic 

60 

Cold 

15 

Severe 

5 

Movement 

Terrain 


10%  Primary  Road 
35%  Secondary  Road 
55%  Cross  Country 


Source:  AMC/TRADOC  Pam- 70-11 


Example 2  Situation.  a  self-propelled  howitzer  is 

expected  to  fire  300  rounds  doily  and  to 
operate  20  hours  doily.  Travel  between 
firing  locations  and  the  resupply  point  will 
probably  total  15  miles  daily.  The 
relationship  among  the  metrics  is  assumed  to 
be  constant  for  logistics  planning  purposes. 

Results.  The  analyst  decides  to  normalize  in 
order  to  simplify  future  computations.  He 
selects  operating  hours  as  the  prime 
operating  metric  and  expresses  the  other 
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metrics  in  terms  of  system  operating  hours. 
The  analyst  obtains  the  following  conversion 
factors: 


Rounds 


Operating  Hour 


Rounds 
300  - 

Day  Rounds 

-  =  15  - 

Operating  Hours  Operating  Hour 


Day 


Miles 


Operating  Hour 


Miles 
15  - 

Day  Miles 

-  =  .75  - 

Operating  Hours  Operating  Hour 

Day 


Action  Step  4:  Compute  System  Usage/Activity  Rate 

Requirement  The  final  action  in  the  mission  analysis 

process  is  to  calculate  the  usage/activity 
rate  for  each  system.  The  analyst  miist 
combine  the  system  operating  metrics,  the 
sequence  of  mission  events,  and  the  scenario 
requirements  contained  in  the  Mission 
Profile/Operational  Mode  Summary  to  determine 
the  usage/activity  rate  for  one  cycle  of 
mission  events.  The  usage/activity  rate  is 
also  determined  for  the  total  number  of 
cycles  necessary  to  satisfy  the  scenario 
requirements. 


Objective 


The  purpose  of  this  action  step  is  to  compute 
the  usage/activity  rate  for  each  system. 
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Procedures 


1.  The  analyst  applies  the  operating  metrics 
identified  in  Action  Step  3  to  the  sequence 
or  cycle  of  mission  events  determined  in 
Action  Step  2.  For  each  mission  event,  the 
analyst  determines  a  numerical  value  for  the 
metric.  The  analyst  obtains  values  through 
logic  and  research.  Professional  judgment  is 
also  exercised  by  the  analyst  and 
subject-matter  experts,  particularly  combat 
developers  for  the  system’s  mission  area. 

2.  The  analyst  aggregates  the  values 
obtained  for  each  mission  event.  The  result 
of  this  process  is  a  mission  event  sequence 
quantified  by  the  number  of  operating  metrics 
required  to  perform  one  full  sequence. 

3.  The  analyst  applies  the  total  expected 
usage  requirements  in  the  Mission 
Profile/Operational  Mode  Summary  (MP/OMS)  to 
the  cycle  of  mission  events  determined  in 
Procedures  1  and  2.  An  MP/OMS  may  describe 
the  expected  percentage  of  time  the  system 
will  spend  in  different  operational  modes 
(e.g.,  surge,  intense,  sustained,  normal)  on 
the  battlefield. 

The  analyst  should  obtain  a  value  for 
expected  usage  during  a  period  which  is  a 
composite  of  these  different  modes.  The 
composite  is  a  weighted  average,  where  the 
weights  are  established  by  the  expected  time 
percentages  provided  in  the  MP/OMS. 

4.  The  total  system  usage/activity  rate  for 
a  period  is  the  product  of  the  usage/activity 
in  one  mission  event  cycle  and  the  number  of 
cycles  required  to  satisfy  the 
mission-essential  usage  prescribed  by  the 
MP/OMS. 
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Examples 

Example  1  Situation.  The  missile  launcher  described  in 

Action  Step  2  has  three  operational  modes 
(see  Table  1.2-3) . 


Table  7.2-3.  Operational  Modes 


MODE 

Surge 

Intense 

Sustained 

Missiles 

Launched 

Per  Week 

150 

100 

60 

Expected 
Percentage 
of  Time 
in  Mode 

10 

35 

55 

The  analyst  must  calculate  the  average  number 
of  missiles  fired  per  week. 

Results.  The  analyst  obtains  the  following 
results; 

Missiles/veek  * 

(150  X  .10)  (100  X  .  35)  ♦  (60  x  .55) 

«  15  ♦  35  ♦  33 

•  03  missiles/week 

Example 2  Situation.  The  situation  of  the  previous 

example  is  continued  here.  The  analyst  must 
obtain  the  total  distance  traveled  during  one 
mission  event  sequence.  In  constructing  that 
sequence,  the  analyst  notes  that  the  launcher 
may  travel  six  unique  paths  during  a  mission 
event  cycle. 


lA-2d 
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In  examining  the  system's  O&O  plan  and  from 
discussions  with  SMEs,  the  analyst  obtains 
the  frequency,  or  probability,  that  the 
system  will  follow  a  particular  path  as  well 
as  the  average  distances  between  the  points. 
Figure  1.2-5  shows  the  paths  with  their 
associated  probabilities.  Table  1.2-4  lists 
the  distances  between  points. 

Table  1.2-4.  Travel  Distances 


From 

To 

Average 

Distance 

(Miles) 

Resupply  Point 

Launch  Area 

2.0 

Resupply  Point 

Hiding  Area 

l.C 

Launch  Area 

Hiding  Area 

.5 

Launch  Area 

Launch  Area 

3.0 

The  analyst  must  compute  the  average  distance 
traveled  for  one  mission  event  cycle. 


Results.  The  analyst  obtains  the  following 
results: 


Path 

Distance 
Traveled  on 

Path  X 

Path 

Probability 

«  Miles 

1 

1 

♦ 

.5 

4- 

0 

♦  2 
«  3.5 

.10 

.35 

2 

1 

♦ 

.5 

4- 

3 

♦  2 
«  6.5 

.25 

1.625 

3 

1 

♦ 

.5 

4- 

.5 

♦  .5  ♦  2 

«  4.5 

.25 

1.  125 

4 

2 

♦ 

.5 

4> 

.5 

♦  2 
«  5.0 

.10 

.50 

I 
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Path 

Distance 

Traveled  on  Path 

Path 

X  Probability  * 

Miles 

5 

2  +  3  +  2 

=  7.0 

.15 

1.05 

6 

2  +  0  +  2 

*  4.0 

.15 

.60 

TOTAL  5.25  miles 


Example  3  Situation.  The  analyst  must  determine  the 

miles  traveled  to  complete  the  weekly  launch 
requirement  of  83  missiles  as  determined  in 
Example  1. 

Reaulta.  The  analyst  obtains  the  following 
results: 


missiles 

83  - 

week 


2  missiles 


cycle 


mi  les 

X  5.25  -  *  217.9  miles 

cycle 
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Functional  Requirements  Analysis 


Overview 


Functional  Requirements  Analysis  determines 
the  range  (what)  and  depth  (to  what  extent 
and/or  how  well)  of  the  functions  that  the 
system  is  required  to  perform  on  the 
battlefield.  In  theory,  new  systems  are 
required  because  of  (1)  recognized 
deficiencies  in  existing  systems  or  (2)  the 
lack  of  any  existing  system  which  is  capable 
of  responding  to  the  perceived  threat. 

0MB  Circular  A-109  (Major  System 
Acquisitions)  specifies  that  a  ^--w  system 
requirement  must  be  justified  oy  showing  how 
that  system's  capability  fulfills  a  mission 
need.  The  objective  of  the  Army's 
Mission  Area  Analysis  (MAA)  process  is  to 
provide  this  justification. 

The  MAA  is  a  valuable  resource  for  the 
HARDMAN  analyst  in  determining  functional 
requirements  of  a  new  system.  It  is 
especially  valuable  if  it  includes  the 
specific  logic  leading  to  the  system's 
justification.  However,  the  MAA's  usefulness 
is  limited  for  two  reasons. 

First,  the  MAA  process  is  designed  to  address 
deficiencies  in  current  capability,  whether 
in  materiel  systems,  training,  doctrine,  or 
organizations.  Thus,  if  an  MAA  produces  a 
requirement  for  a  new  materiel  system, 
in-depth  discussions  are  usually  limited  to 
deficiencies  that  the  new  system  must 
overcome.  Existing,  satisfactory 
capabilities  are  assumed  to  continue. 

Clearly,  the  subset  of  requirements 
consisting  only  of  the  deficiencies  to  be 
overcome  is  insufficient  for  the  HARDMAN 
analyst.  Manpower,  personnel,  and  training 
(MPT)  requirements  must  be  developed  for  the 
entire  system. 


The  second  limiting  factor  is  timeliness. 


Because  MAAs  are  conducted  on  a  two-  or 
three-year  cycle,  system  requirements 
developed  out  of  cycle  may  only  be  indirectly 
related  to  the  last  MAA.  Therefore,  the 
relationship  of  the  functional  requirements 
of  the  system  to  its  overall  contribution  to 
mission  performance  should  be  identified. 

Thus,  the  basis  for  justifying  a  new  system 
rests  directly  on  its  ability  to  perform  on 
the  battlefield  and  to  do  so  in  a  manner 
superior  to  that  of  the  existing  system.  The 
question  of  what  is  specifically  required  of 
the  system  on  the  battlefield  is  essential  to 
the  evolution  of  systems  in  the  acquisition 
process.  The  purpose  of  Functional 
Requirements  Analyis  is  to  answer  this 
question  in  sufficient  detail  to  support 
subsequent  analyses. 


The  emphasis  placed  on  detailed  delineation 
of  system  functions  through  Functional 
Requirements  Analysis  depends  on  the  new 
system's  position  in  the  acquisition  process. 
Experience  has  shown  that  this  analysis 
should  be  emphasized  early  in  the  acquisition 
process.  ^ 

Typically,  the  relationships  among  missions, 
functions,  and  design  are  ambiguously  or 
incompletely  spe»  ified  in  this  phase.  As 
more  information  becomes  available  and  design 
options  narrow,  the  analyst  and  analysis 
manager  may  choose  to  give  less  emphasis  to 
this  substep. 

Functional  Requirements  Analysis  is  a  means 
to  the  end  of  specifying  the  system  in  detail 
sufficient  to  support  subsequent  analyses. 

If  the  system  design  is  already  detailed, 
this  end  may  be  accomplished. 

Of  course,  experience  has  also  shown  that 
detailed  design  may  have  overtaken  the 
resolution  of  uncertainty  in  the  requirements 
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phase.  If  this  is  the  case,  Functional 
Requirements  Analysis  may  assist  in  resolving 
uncertainty. 

Figure  lB-1  depicts  the  logic  flow  for 
determining  functional  requirements.  As 
shown  in  the  figure,  this  substep  group 
contains  one  substep. 


V 
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Determine  Functional  Requirements 


Objectives 


This  substep  identifies  functions  necessary 
to  perform  battlefield  missions  assigned  to 
the  system  under  analysis.  These  functions 
are  analyzed  in  the  context  of  (1)  what 
conditions  are  likely  to  be  present  on  the 
battlefield  and  (2)  what  level  of  performance 
is  desired.  System  functional  requirements 
are  thus  identified. 

A  system  functional  requirement  is  an 
inherent  characteristic  or  capability  which 
allows  the  system  to  perform  the  required 
function  to  the  level  of  desired  performance. 
Describing  the  functions  and  the  performance 
requirements  constitutes  describing  the 
system  functional  requirements. 

When  the  functional  requirements  have  been 
sufficiently  described,  the  functions  may  be 
allocated  to  one  of  the  three  elements  which 
comprise  a  system  —  equipment,  people,  or 
information.  The  definition  of  what 
constitutes  a  "sufficient"  description  is 
subjective.  Functional  requirements  need 
only  be  detailed  enough  to  support  allocating 
system  functions  to  one  of  the  three  system 
elements. 

In  HARDMAN,  as  in  the  design  process, 
functions  are  first  allocated  to 
equipment/hardware.  Generic  equipment  which 
performs  or  supports  performance  of  the 
function  is  identified.  Functions  not 
allocated  to  generic  equipment  remain  to  be 
accomplished  by  the  other  system  elements, 
people,  and  information. 


Input 


Input  to  this  substep  from  other  HARDMAN 
substeps  includes  the  general  mission  area 
context  of  the  system  under  analysis  and 
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Specific  system  missions  from  Substep  1.1 
(Identify  General  Mission  Requirements)  and  a 
description  of  the  Predecessor  System  from 
Substep  1.5  (Identify  Predecessor  System). 

Input  from  other  sources  includes  the  most 
recent  Mission  Area  Analysis  (MAA)  for  the 
system's  mission  area;  system  requirements 
documents,  such  as  the  Justification  for 
Major  System  New  Start  (JMSNS)  and  the 
statement  of  Required  Operational  Capability 
(ROC);  doctrinal  publications,  such  as  the 
how-to-fight  field  manual  series  which 
pertains  to  the  system's  mission  area;  and 
the  system's  Operational  and  Organizational 
(O&O)  Plan. 


Product  The  result  of  this  substep  is  a  list  of 

required  system  functions,  functional 
requirements,  and  the  generic  equipment  which 
supports  each  function. 


Logic  By  beginning  at  a  high  level  of  abstraction 

and  becoming  progressively  more  detailed,  the 
analyst  can  generate  a  hierarchy  of  missions, 
functions,  and  functional  requirements  which 
supports  allocation  of  functions  to  system 
elements.  Figure  1.3-1  depicts  the  logic 
flow  for  determining  functional  requirements. 
As  shown  in  the  figure,  this  substep  contains 
three  action  steps. 


Action  Steps 


Action  Step  1:  Identify  System  Functions 


Requirements  "Functions"  can  be  defined  as  actions  that  a 

system  performs  to  accomplish  its  mission.  A 
finite  set  of  generic  functions  applies  to 
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Figure  1.3*1.  Determine  Functional  Requirements  logic. 
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Objective 


Procedures 


all  systems.  From  the  generic  set,  the 
analyst  must  identify  the  specific  functions 
which  apply  to  the  system  under  analysis. 

The  analyst  must  also  subdivide  general, 
high-level  functions  into  progressively  more 
detailed  functions  which  apply  to  lower-level 
system  elements. 


In  this  step,  the  system  functions  associated 
with  the  system's  various  missions  are 
identified. 


1.  The  analyst  must  first  identify  the 
functions  which  apply  to  the  system  under 
analysis.  The  analyst  must  be  careful  to 
distinguish  functions  from  missions  and 
functional  requirements.  Functions  are 
actions  which  must  be  carried  out  in  order  to 
accomplish  a  mission.  Thus,  a  mission 
assigned  to  a  system  is  accomplished  through 
the  system's  capability  to  perform  certain 
functions.  The  functions  may  be  performed  by 
the  system  as  a  whole  (high-level  functions) 
or  by  specific  combinations  of  system 
elements  (lower-level  functions*,  or 
sub-functions) . 

A  functional  requirement  describes  the 
attributes  or  capabilities  required  to  be 
inherent  in  the  system  so  the  function  can  be 
successfully  performed  under  operational 
conditions  to  the  level  of  performance 
required.  Table  1.3-1  summarizes  the 
distinctions  among  missions,  functions,  and 
functional  requirements. 

Table  1.3-2  provides  a  suggested  list  of 
generic  functions  and  sub-f unct ions.  For  a 
particular  mission  assigned  to  the  system, 
the  analyst  would  select  from  the  list  those 
high-level  functions  needed  to  perform  the 
mission.  After  all  missions  have  been 
reviewed,  the  analyst  will  have  produced  a 
list  of  the  functions  required  by  the  system. 
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Table  1.3-1.  Mission/Function 

Applies  to: 

Mission 

Actions  to  be 
accomplished 
by  a  command 

Forces/units/systems 
accomplished 
of  systems/single 
systems) 

Function 

Actions  required 
to  perform  missions 

System  (interaction 
of  all  system 
elements) 

Sub¬ 

function 

Actions  required  to 
perform  function 

Sub-system/compo- 
nents  (interaction 
of  particular 
system  elements) 

Functional 

Require¬ 

ment 

Attributes  or  capa¬ 
bilities  required 
for  performance  of 
funct ion/sub-f unct ion 

Functions  and 
Sub-functions 

Table  1.3-2.  Generic  Functions 


Type 

Funct ion 

Sub-function 

Operate 
— Active 

Shoot 

Aim 

Load 

Fire 

Move 

Emplace 

Transit 

Navigate 

Disemploce 

Commun i - 
cate 

Transmit 

Receive 

Command  and 
Control 

Sense 

Process 

Compare 

Decide 

Act 
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Table  1.3-2. 

Generic  Functions  [coni] 

Type 

Function 

Sub-funct ion 

Intelli¬ 

gence 

Sense 

Process 

Compare 

Analyze 

Dissemi¬ 

nate 

Operate 
— Passive 

Survive 

Attack 

RAM-D 

NBC 

Natural 

Environ¬ 

ment 

Support 

Battle 

Support 

Supply 

Maintain 

Transport 

2.  For  each  function,  the  analyst  determines 
which  sub-functions  apply.  While  high-level 
functions  apply  to  the  system  as  a  whole, 
sub-functions  generally  apply  to  a  subset  of 
system  elements.  Progressively  subdividing 
the  functions  into  more  detailed  and  specific 
sub-functions  allows  the  analyst  to  make  a 
better  choice  of  generic  equipment  in  Action 
Step  3.  The  sub-f unct ions  contained  in  Table 
1.3-2  are  suggestions.  The  analyst  should 
describe  sub-funct ions  most  suited  to  the 
system  under  analysis.  If  the  list  in  Table 
1.3-2  is  used,  the  analyst  should  note 
several  factors: 

•  Because  functions  are  primarily 

active  behaviors,  verbs  describe  their 
sub-functions.  The  exception  is  the 
Survive  function,  which  is  a  passive 
behavior.  In  this  case,  the  sub-functions 
describe  the  system's  ability  to  withstand 
or  survive  the  specific  type  of  condition 
indicated. 
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•  The  Battle  Support  function  occurs 
largely  outside  the  system  boundary,  in 
other  words,  a  system  is  typically 
supported  by  its  organization  and 
logistics  environment.  However,  Battle 
Support  and  its  sub-functions  are  relevant 
system  functions  because  the  overall 
ability  of  the  environment  to  support  the 
system  may  depend  on  inherent  system 
characteristics. 

For  example,  Supply  may  be  affected  by  the 
system's  storage  capacity  for  fuel  and 
ammunition.  Transport  by  any  means  other 
than  the  system's  organic  capability  is 
affected  by  the  system's  size  and  weight. 

•  Command/Control  and  Intelligence  consist 
of  similar  sub-functions,  but  the 
distinction  between  the  two  is  the 
traditional  one.  Command  and  Control 
pertains  to  information  on  friendly 
forces,  while  Intelligence  concerns 
information  on  the  enemy. 

3.  To  accomplish  any  particular  mission, 
sub-functions  from  different  functional  areas 
will  usually  be  required.  The  analyst  must 
take  care  to  select  only  those  system 
functions  which  fall  within  the  boundary  of 
the  system  under  analysis.  It  may  be 
necessary  to  analyze  functions  which  are  not 
included  within  the  system  but  are  essential 
to  system  operation.  The  analyst  must 
distinguish  between  the  two  categories. 


Example  Situation.  The  system  under  analysis  is  «) 

new  howitzer  which  is  part  of  a  larger  fire 
support  system.  For  a  typical  target 
engagement,  the  analyst  must  identify  the 
functions  required  of  the  fire  support  system 
and  which  of  these  must  be  present  in  the 
howitzer.  The  requirement  for  the  new 
howitzer  specifies  an  on-board  technical  fire 
control  capability,  i.e.,  computing  the 
gunnery  solution  previously  performed  in  a 
Fire  Direction  Center. 
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Results.  The  analyst  researches  the  actions 
required  in  a  typical  target  engagement.  The 
results  of  that  research  effort  are  presented 
in  Table  1.3-3. 


Table  1.3-3.  Functions  Example 


Within 


Required  Action 

Function 

Sub-Funct  io;i 

How  it 

Detect  Target 

Intelligence 

Sense 

No 

Identify  Target 

Intelligence 

Process 

No 

Obtain  Target  Data 

Intelligence 

Sense 

No 

Call  For  Fire 

Communicate 

Transmit 

No 

Accept  Call 

Communicate 

Receive 

No 

Determine  Target 
Priority 

Command  and 
Control 

Decide 

No 

Issue  Attack  Order 

Command  and 
Control 

Act 

No 

Transmit  Order/Data 

Communicate 

Transmit 

No 

Receive  Order/Data 

Communicate 

Receive 

Yes 

Obtain  Firing 
Solution 

Command  and 
Control 

Process 

Yes 

Apply  Firing 

Shoot 

Aim 

Yes 

Solution 

Load  Projectile 

Shoot 

Load 

Yes 

Load  Charge 

Shoot 

Load 

Yes 

Fire 

Shoot 

Fire 

Yes 

Report  Rounds 

Communicate 

Transmit 

Yes 

Complete 

Observe  Target 

Intelligence 

Sense 

No 

Damage 

Assess  Target 

Intelligence 

Process 

No 

Damage 

Action  Step  2:  Determine  System  Functional  Requirements 

Requirements  A  system  functional  requirement  states  the 

attributes  or  capabilities  required  to  be 
present  in  system  elements  so  that  each 
element,  and  the  system  as  a  whole,  can 
accomplish  its  assigned  actions. 

A  function  states  what  must  be  done.  A 
functional  requirement  states  under  what 
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Objective 


Procedures 


conditions  the  function  must  be  performed  and 
the  degree  or  level  of  performance  required. 
For  each  system  function,  the  analyst 
determines  the  functional  requirements  by 
analyzing  the  system's  operational 
environment  and  the  performance  requirements 
specified  for  the  new  system. 


The  purpose  of  this  step  is  to  list  the 
attributes  or  capabilities  that  the 
components  of  the  system  require  in  order  to 
carry  out  their  assigned  responsibilities. 


1.  For  each  function  and/or  sub-function, 
the  analyst  describes  two  factors  which 
comprise  a  functional  requirement  statement: 


•  Performance  Measure:  The  qualitative 
description  of  how  the  performance  of  the 
function  will  be  assessed 

•  Performance  Standard:  The  quantitative 
goal  or  criteria  against  which  performance 
of  the  function  will  be  assessed 


2.  No  standard  list  of  performance  measures 
exists  for  the  functions  and  sub-functions 
described  in  the  previous  action  step. 
Performance  measures  vary  with  the  system 
under  analysis  and  the  mission  area  to  which 
it  belongs.  The  analyst  may  identify 
potential  performance  measures  and  standards 
for  the  system  under  analysis  by  examining 
available  requirements  documentation,  such  as 
the  JMSNS  or  the  ROC. 

Any  measure  describing  the  p>otential 
performance  of  the  system  under  analysis 
should  be  treated  as  a  performance  measure. 

A  function  may  have  more  than  one  performance 
measure  associated  with  it.  Conversely,  no 
performance  measures  may  be  associated  with  a 
particular  function  if  the  function  is 
subsumed  in  other  functions. 
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3.  Performance  standards  also  vary  with  the 
system  under  analysis  and  the  mission  area  to 
which  it  belongs.  The  mission  area  context 
of  the  system  is  especially  useful  to  the 
analyst  in  determining  performance  standards 
if  none  is  available  from  system 
documentation. 

For  example,  if  the  new  system  requirement  is 
for  a  direct  fire  anti-tank  weapon  in  the 
Close  Combat — Light  mission  area,  then  for 
the  performance  measure  of  maximum  effective 
range  the  analyst  might  assign  a  standard  of 
1200  meters  if  no  standard  is  specified. 

(This  distance  is  roughly  the  dividing  line 
for  anti-tank  weapons  assigned  to  Close 
Combat — Light  versus  those  assigned  to  Close 
Combat — Heavy,  although  responsibi 1 it ies 
overlap. ) 

Performance  standards  for  the  system  under 
analysis  may  be  expressed  by  referring  to 
existing  systems  (e.g.,  improve  accuracy  10 
percent  over  current  system);  by  specific 
quantitative  values  (e.g.,  minimum 
cross-country  speed  equals  15  miles  per 
hour);  or  by  go/no-go  terms  (e.g.,  must  fire 
Copperhead) . 

4.  A  functional  requirement  results *when  the 
function  and/or  subfunction  has  been  assigned 
both  a  performance  measure  and  a  performance 
standard.  Functions  and  sub-function 
provided  earlier  are  at  a  high  level  of 
abstraction,  while  performance  measures  and 
standards  are  likely  to  be  far  more  detailed. 

The  analyst  uses  information  conveyed  by  the 
performance  measures  and  standards  to  develop 
progressively  more  detailed  descriptions  of 
functions,  i.e.,  those  that  apply  to  lower 
levels  of  the  system.  The  analyst  repeats 
Action  Steps  1  and  2  to  insure  that  the 
specificity  of  the  terms  used  for  functions, 
measures,  and  standards  parallel  each  other. 
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Example  Table  1.3'4  provides  an  example  of 

performance  measures  and  standards  for  a 
self-propelled  howitzer's  shoot  function. 

Table  1.3-4.  Performance  Measures  and  Standards 


Performance 

Performance 

Function 

Measure 

Standard 

Shoot 

Response  time 

Minimum:  15  seconds 
Maximum:  45  seconds 

Rate  of  fire 

Maximum:  16  rounds/ 
minute 

Minimum:  8  rounds/ 
minute 

Range 

Terminal 

Effects 

Minimum:  1000  meters 
Maximum:  30,000  meters 
unassisted 

Maximum 

effective:  22,000 
meters  unassisted 

— Accuracy 

Less  than  or  equal  to 

20  meters  range  error 

— Round  type 

Less  than  or  equal  to 

10  meters  deflection 
error 

— Target  type 

DPICM,  Copperhead,  NBC 

personnel,  tanks 


Action  Step  3:  Allocate  Functions 


Requlrementa  When  the  system  and  end  item  functional 

requirements  are  identified,  the  functional 
requirements  are  considered  to  be  delineated. 
The  definition  of  what  constitutes 
delineation  of  a  functional  requirement  is  a 
subjective  one.  It  depends  on  the  degree  to 
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Objective 


Procedures 


which  the  functional  requirement  supports  an 
allocation  of  the  function  to  one  of  the 
three  system  components:  hardware/equipment, 
people,  or  information. 


The  objective  of  this  action  step  is-  to 
determine  which  system  functions  are 
accomplished  by  equipment  and  which  are 
performed  by  the  system's  operators. 


1.  In  HAROMAK,  as  in  the  system  design 
process,  functions  are  first  allocated  to 
equipment/hardware.  In  constructing  a  system 
design  responsive  to  a  set  of  functional 
requirements,  the  designer  implicitly 
allocates  the  remainder  of  the  functions  to 
people  and  information  singly,  together,  and 
in  contact  with  the  hardware.  Allocation  to 
equipment  is  conceptually  easier  because  it 
is  less  abstract. 

2.  If  a  Predecessor  System  exists,  it  can 
form  the  basis  for  an  initial  functional 
allocation.  Th*  Predecessor  System  is 
helpful  to  analyst  because,  until  this 
point,  the  analysis  has  been  somewhat 
abstract.  The  Predecessor  System  is  a 
tangible  embodiment  of  functions  which  have 
been  allocated  to  equipment. 

The  analyst  consults  with  the  Engineering 
analyst  to  determine  whether  a  Predecessor 
System  was  identified  in  Substep  1.5 
(Identify  Predecessor  System).  For 
Predecessor  System  functions  which  remain 
unchanged,  the  analyst  determines  the  generic 
type  of  equipment  found  in  the  Predecessor 
System  and  allocates  the  functions  to  that 
generic  equipment. 
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Exampit 


3.  If  no  Predecessor  System  exists,  or  if 
the  functions  required  of  the  new  system  are 
Substantially  different  from  those  of  the 
Predecessor,  the  analyst  must  identify 
generic  equipment  to  which  the  functions  may 
be  allocated.  This  involves  research,  logic, 
and  the  exercise  of  professional  judgment. 

The  analyst  again  consults  the  Engineering 
analyst  for  assistance. 

4.  When  all  functions  have  been  analyzed  and 
generic  equipment  have  been  selected  on  the 
basis  of  functional  requirements,  the  analyst 
allocates  the  remaining  functions  to  the 
system  operators  and  maintainers.  Allocation 
of  functions  to  equipment  first  allows 
identification  of  tasks  in  Substep  1.10 
(Determine  Generic  Tasks)  to  be  characterized 
as  equipment  or  non-equipment  based. 
Identification  of  generic  equipment  allows 
identification  of  generic  tasks.  As  the 
equipment  becomes  more  specific,  so  may  the 
task. 


The  new  system  is  a  self-propelled  missile 
launcher.  An  example  of  the  allocat-ion  flow 
of  functions  to  specific  equipment  features 
of  the  launcher  is  displayed  in  Figure  1.3-2. 


Syittm  Function 


Performance  Measure 


Afilttv 


Generic  Subsystem 


Substep  Group  1C _ 

Equipment  Comparability  Analysis 


Overview 


Comparability  analysis  derives  systematic 
estimates  of  the  human  resource  requirements 
of  emerging  weapon  systems  by  extrapolating 
from  the  known  requirements  of  similar 
operational  systems  and  subsystems. 

In  Equipment  Comparability  Analysis,  the 
system  under  analysis  is  evaluated  and 
interpreted  in  generic,  then  more  specfic 
design  terms.  Equipment  Comparability 
Analysis  is  the  analyst's  link  between 
knowing  what  the  system  must  do  —  its 
functional  requirements  —  and  the  specific 
equipment  configurations  assigned  to  do  it. 

Equipment  Comparability  Analysis  produces 
specific  equipment  lists  for  the  Baseline 
Comparison  System  (BCS)  and  each  Proposed 
System  alternative.  It  also  produces  an 
index  of  design  differences  between  the  BCS 
and  each  Proposed  System  alternative.  These 
key  outputs  are  critical,  as  they  determine 
the  validity  of  most  subsequent  steps  and  of 
the  analysis  as  a  whole. 

The  Mission  Area  Analysis  (MAA)  phase  of  the 
LCSMM  culminates  the  Army's  assessment  of  its 
mission  needs.  If  a  requirement  for  a  new 
weapon  system  emerges  from  the  MAA,  it 
results  from  perceived  deficiencies  in  the 
Predecessor  System,  a  system  currently  in  the 
Army  inventory. 

By  definition,  the  Predecessor  System  is 
unable  to  satisfy  the  functional  requirements 
of  the  new  system.  However,  functional 
requirements  information  available  from  an 
MAA  usually  focuses  on  Predecessor  System 
deficiencies,  not  on  the  full  set  of 
functional  requirements  identified  for  the 
new  system.  Substep  Group  IB,  Functional 
Requirements  Analysis,  is  designed  to 
overcome  this  lack  of  information. 
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Comparability  analysis  converts  the 
functional  requirements  of  the  new  system 
into  at  least  two  specific  but  non- integrated 
system  constructs:  the  "Proposed  System"  and 
the  "Baseline  Comparison  System."  These 
constructs  are  developed  by  identifying 
specific  hardware  components  which  can 
perform  system-level  functions  and  tasks. 
Identified  components  must  also  meet  the 
design,  operational,  and  support  needs 
implicit  in  the  functional  requirements. 

The  first  of  these  analytical  constructs,  the 
Proposed  System,  may  incorporate 
technological  advances  likely  to  exist  before 
the  system's  projected  Initial  Operational 
Capability  date.  When  the  analysis  begins, 
one  or  more  alternative  Proposed  Systems  may 
be  presented.  The  number  presented  depends 
on  how  many  unique  solutions  were  offered  by 
the  materiel  developer  or  materiel 
contractors  in  response  to  the  Army's 
statement  of  mission  need  and/or  system 
requirement. 

The  second  system  construct  is  termed  the 
Baseline  Comparison  System  (BCS)  by  MIL-STD 
1308-lA  (Logistic  Support  Analysis).  ^  The  BCS 
may  be  a  current  operational  system  But  is 
much  more  likely  to  be  a  composite  of  current 
operational  systems  and  subsystems.  This 
composite  closely  approximates  the  design, 
operational,  and  support  characteristics 
stipulated  for  the  developmental  system. 
Components  of  the  BCS  may  be  drawn  from  the 
Predecessor  System  and  other  comparable 
existing  systems  in  the  DoD/NATO  inventory. 

Data  are  collected  about  the  BCS  and  the 
Proposed  System  alternatives  for 
consideration  in  this  and  later  substep 
groups.  Maturity  of  the  data  used  for  the 
BCS  and  the  Proposed  Systems  forms  a  crucial 
distinction  between  the  two.  To  qualify  for 
inclusion  in  the  BCS,  a  candidate  component 
must  have  mature  data  available.  Such  data 
are  needed  to  demonstrate  the  likely  MPT 
impacts  under  field  conditions. 
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The  Proposed  System,  on  the  other  hand,  is 
defined  as  less  technologically  mature.  As 
such,  it  can  include  data  from  tests  or 
engineering  estimates.  Differences  between 
the  two  data  sets  are  analyzed  to  identify 
design  changes  between  the  BCS  and  Proposed 
Systems.  These  design  differences  form  the 
basis  for  the  distinction  between  the  BCS  and 
Proposed  System  MPT  requirements  calculated 
in  subsequent  steps. 


Logic  Table  lC-1  summarizes  the  distinctions 

between  the  Predecessor,  Baseline  Comparison, 
and  Proposed  Systems.  One  should  not  infer 
that  the  Proposed  System  is  always  developed 
first  and  then  followed  by  the  BCS. 

Experience  has  shown  that  if  Proposed  System 
alternatives  have  been  identified,  Equipment 
Comparability  Analysis  is  somewhat  easier  to 
accomplish.  From  the  analyst's  point  of 
view,  this  situation  is  preferable. 

However,  definitive  statements  of  system 
solutions,  i.e.,  the  Proposed  System 
alternatives,  are  not  always  available, 
either  from  a  materiel  contractor  or  from  the 
Army  agency  sponsoring  system  development. 
Often,  Proposed  System  alternatives  are 
identified  and,  upon  examination,  found 
lacking  in  complete,  systematic  descriptions. 

In  both  cases  —  where  Proposed  System 
alternatives  did  not  exist  or  were  only 
partially  described  —  the  analyst  would 
develop  the  BCS  first.  Composite  Proposed 
System  alternatives  are  then  developed  with 
information  from  the  BCS,  the  technological 
base,  and  the  research  and  development 
community  at  large. 

Figure  lC-1  presents  an  overview  of  the  logic 
used  in  Equipment  Comparability  Analysis. 


Output 


Figure  IC-I.  Logic  flow  for  Equipment  Comparabi*'^  Analysis. 
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^1 


Note  that  the  order  in  which  the  five 
substeps  are  accomplished  tends  to  be  a 
function  of  whether  Proposed  System 
alternatives  are  available.  Upcoming 
sections  will  describe  these  substeps  in 
detail: 

1.4  Establish  Generic  Equipment  Structure 

1.5  Identify  Predecessor  System 

1.6  Establish  Baseline  Comparison  System 

1.7  Establish  Proposed  System 

1.8  Determine  Design  Differences 
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Establish  Generic  Equipment  Structure 


Overview 


Input 


Products 


Logic 


The  materiel  aspects  of  the  system  under 
analysis  may  be  represented  in  a  hierarchical 
manner.  The  purpose  of  the  hierarchy  is  to 
establish  a  systematic  breakdown  of  the 
system  into  its  functional  groups,  basic 
systems,  subsystems,  components,  assemblies, 
and  parts.  When  coupled  with  an  indexing 
mechanism,  the  hierarchy  becomes  an  analysis 
tool  for  comparing  the  Predecessor,  Baseline 
Comparison,  and  Proposed  System  alternatives. 

The  objectives  of  this  substep  are  to 
establish  the  equipment  hierarchy,  select  an 
indexing  mechanism,  and  arrange  the  generic 
equipment  identified  by  functional  allocation 
in  appropriate  locations  in  the  hierarchy. 

The  result  is  a  generic  equipment  structure, 
which  forms  the  basis  for  comparisons  of 
Predecessor,  BCS,  and  Proposed  System 
alternatives  in  the  substeps  which  follow. 


Input  from  HARDMAN  Substep  1.3  (Determine 
Functional  Requirements)  includes  a  list  of 
generic  equipment  which  has  been  allocated  to 
system  functions.  Other  input  includes 
standard  indexing  mechanisms,  such  as 
Functional  Group  Codes,  Work  Unit  Codes,  or 
Logistics  Support  Analysis  Control  Numbers, 
which  may  be  available  from  various  sources. 

The  output  of  this  substep  is  a  generic 
equipment  structure  constructed  by  Equipment 
Identification  Code  (EIC).  The  generic 
structure  will  be  used  to  develop  both  the 
BCS  and  Proposed  System  equipment  structures. 


The  HARDMAN  analysis  normally  progresses  from 
generic  to  specific.  The  generic  equipment 
structure  is  a  systematic  arrangement  of  all 
equipment  judged  necessary  to  perform  the 
emerging  system's  stated  functions.  The 
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Action  Steps 

Action  Step  1: 

Requirtmtntt 


Objectiv# 


Proctdurtt 


descriptions  of  the  equipment  are  generic; 
that  is,  they  are  at  a  higher  level  of 
abstraction  than  particular  examples  of  the 
equipment  are.  Specific  examples  will  be 
substituted  in  the  development  of  the  BCS  and 
Proposed  System  equipment  structures.  The 
generic  equipment  structure  serves  as  the 
basis  for  those  efforts. 

Figure  1.4-1  depicts  the  logic  flow  for 
establishing  the  generic  equipment  structure. 
As  the  figure  shows,  this  substep  consists  of 
two  action  steps. 


Develop  Equipment  Identification  Code  lEIC]  Structure 


with  the  exception  of  vehicles  and  support 
equipm^nc,  the  Army  does  not  have  a  standard 
equipment  structure  for  its  systems.  Users 
or  analysts  are  permitted  to  develop 
equipment  structures  which  best  suit  their 
own  purposes.  In  this  substep,  the  HARDMAN 
analyst  must  develop  an  Equipment 
Identification  Code  (EIC)  structure  for  use 
in  the  substeps  which  follow. 


The  objective  of  Action  Step  1  is  to 
identify,  select,  and/or  develop  an  Equipment 
Identification  Code  structure  for  use  in 
other  HARDMAN  substeps. 


Military  Standard  1388-lA  (Logistic  Support 
Analysis)  defines  a  Functional  Group  Code  as 
a  standard  indexing  mechanism  which  parcels 
the  weapon  system  into  its  functional  groups, 
basic  systems,  subsystems,  components, 
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assemblies  and  parts.  Other  codes  and 
terminologies  have  the  same  effect  as  the 
Functional  Group  Code. 

Among  these  are  the  Work  Unit  Code  (WUC), 

Work  Breakdown  Structure  (WBS), 

Equipment  Identification  Code  (EIC),  and  the 
Logistics  Support  Analysis  Control  Number 
(LCN).  All  of  these  terms  are  used  by  the 
military  services  in  different  circumstances. 
HARDMAN  employs  the  most  generic  terminology, 
Equipment  Identification  Code  (EIC). 

The  EIC  structure  is  used  to  differentiate 
the  various  levels  of  the  equipment  hierarchy 
to  which  it  is  applied.  "Level  of  indenture" 
refers  to  a  specific  level  within  this 
hierarchy.  Typically,  a  system  contains  five 
or  six  levels  of  indenture.  These  levels  are 
defined  as  follows: 


•  End  item  —  A  final  combination  of  end 
products,  component  parts,  and/or 
materiel  which  is  ready  for  its  intended 
use,  e.g.,  Missile,  Tank,  Aircraft, 

and  Radar. 

•  System  —  A  complete  system  within  an 
overall  system  such  as  Hydraulic  System, 
Avionics  System,  Armament  System,  etc. 

•  Subsystem  —  A  major  portion  of  a  system 
that  performs  a  specific  function  in  the 
overall  operational  function  of  the  system 
e.g.,  the  Receiver/Transmitter  Set,  Radar 
Set,  etc. 

•  Component /Assembly  —  A  number  of  parts  or 
subassemblies  or  any  combination  thereof 
joined  together  to  perform  a  specific  func 
tion.  Within  the  scope  of  this  document, 
this  term  applies  to  items  that  cannot  be 
further  disassembled  or  repaired  without 
shop  facilities.  Examples  include  signal 
data  converter,  antenna,  amplifier 
assembly,  etc. 
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•  Subcomponent/Assembly  —  Those  parts  or 
subassemblies  comprising  the  next  higher 
assembly.  This  level  may  not  be  applicable 

•  Part  —  One  piece,  or  two  or  more  pieces 
joined  together,  which  is  not  normally 
subject  to  disassembly  without  destruction 
of  designed  use. 


Figure  1.4-2  provides  an  example  of  a  system 
with  five  levels  of  indenture.  Example  EICs 
are  shown  in  the  upper  left  corner  of  each 
rectangle.  The  precise  form  of  the  EIC 
structure  is  left  to  the  judgment  of  the 
analyst,  subject  to  the  condition  that  codes 
should  be  assigned  in  a  manner  that  allows 
each  item  to  be  uniquely  identified  as  part 
of  its  next  higher  assembly. 

A  typical  structure  will  have  two  places  for 
each  level  of  indenture  except  the  end  item. 
The  characters  may  be  alpha,  numeric,  or  a 
combination  of  those  at  any  level,  depending 
on  the  characteristics  of  the  system  under 
analysis. 

The  Army  has  no  standard  EIC  structure  for 
all  systems.  Technical  Bulletin  750-93-1 
(Functional  Grouping  Codes;  Combat, 

Tactical,  and  Support  Vehicles  and  Special 
Purpose  Equipment)  provides  standard 
Functional  Group  Codes  for  combat,  tactical 
and  support  vehicles,  and  items  of  support 
equipment.  The  analyst  should  use  these 
c^es  if  the  system  under  analysis  falls  into 
one  of  these  categories. 

For  other  types  of  systems,  the  analyst  must 
either  identify  an  existing  EIC  structure 
which  could  serve  as  the  basis  for  the 
HARDMAN  EIC  Structure  or  develop  one  from  a 
combination  of  existing  EIC  structures. 
Existing  EIC  structures  may  be  available  from 
Air  Force  and  Navy,  as  well  as  other  Army 
sources. 


Subsytttm 


Compontnt/ Assembly 


Subcompontnt/Aistfnbly 


Part 


Figurt  1.4-2.  Ltvels  of  indtntura. 
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Exampitt 

Example  1  Table  1.4-1  provides  an  example  of  the 

assignment  of  EICs  to  various  levels  of 
indenture. 

Table  1,4-1,  EIC  Assignment  Example 


Level 


EIC 


Descript  ion 


End  Item 

(Functional)  System 
Subsystem 

Component /Assembly 
Sub-Component / 
Assembly 
Part 


A 

A  02 
A  02  04 
A  02  04  AB 
A  02  04  AB  01 

A  02  04  AB  01  03 


Tank 

Electronic  System 
Radar 
Antenna 

Cable  Assembly 
Clamp 


Examplt2  Table  1.4-2  provides  EICs  from  Technical 

Bulletin  750-93-1  at  the  functional  system, 
or  second,  level  of  indenture. 


Example  3  The  11-  series  of  Department  of  the  Army 

pamphlets  provides  a  useful  cross-reference 
between  the  subdivisions  of  a  weapon  system 
which  are  of  inter'".:^  to  life-cycle  cost 
analysts  and  thos^  .ound  in  Military  Standard 
881  (Work  Breakdown  Stucture  for  Defense 
Materiel  Items).  This  cross-reference  may 
serve  as  a  starting  point  for  the  HARDMAN 
analyst  in  developing  an  EIC  structure  for 
systems  which  cannot  be  accommodated  within 
the  TB  750-93-1  codes.  The  cross-reference 
is  provided  in  Table  1.4-3. 


Table  1.4-2.  TB  750-93-1  Functional  Group  Codes 


01  Engtnt 
02  Clutch 
03  Fuel  Syitam 
04  Exhaust  Systam 
05  Coolinf  Systam 

06  Elactrical  Systam  (Engine  and  vahicuiar. 
ate.) 

07  Transmission 
06  Transfer  AsMrrbly 
00  Propatlar  and  Propallar  Shafts 
10  From  Axia 
•  1  Rear  Axta 

12  Biakas  (Other  than  special  purpoaa) 

13  Wheals  and  Tracks 

14  Siaaring 

15  Frame,  Towing  Attachments,  and 

Drawbars 

16  Springs  and  Shock  Abiorban 

17  Railway  Car  Body  and  Underframa 

18  Body,  Cab,  Ho<<and  Hull 

19  Turret 

20  Hoist,  Winch,  Capstan,  Windlass,  Power 

Control  Unit,  and  Powar-Taka-Offs 

21  Bumpers,  Guards,  and  Marina  Fandan 

22  Body,  Cfwisit  or  Hull,  and  Aaamblv 

Hams 

23  Hydraulic  Uft  Componants  (Exckida 

tractor,  bulkkuar  lifts) 

26  Toob  and  T«t  Equipment 
20  Auxiliary  Generator  and  Engma  and 
Controh  (Special  purpoaa) 

30  Elevators,  Special  Purpoaa  (Hydraulically 
oparstad) 

33  Special  Purpose  Kits 

34  Armament  and  Sighting  and  Fwa  Con* 

trol  (Elactric/Eiactronic)  Malarial 

35  Pulleys,  Baits,  Shafts  (Not  ratatad  to 

other  functional  groups) 

30  Saarchli^it  and  Elactrical  IHuminating 
Equipmant 

4C  Elaciric  Motors  and  Generators  (Other 
than  artgina  aocaaserias) 

42  Elactrical  Equrpmant  (Not  oontainad  in 

other  functional  groups) 

43  Hydraulic,  Fkid,  Air,  and  Vacuum 

Syttams  (Excluda  brake  systam) 

44  Welding,  Mataliii)^,  Metal  Haatmg, 

and  Platiitc  Equipmant 

45  Offioa  Machinery,  Equipmant.  araf  Fur 

nitura  (Induda  household  furniture) 

46  Repair  Equipmant  (Sioai,  clothing,  lax 

tHa) 

47  Gagas  (Non  Elaetricol).  Washing  and 

Measuring  Daviees 

46  Food  Proparation  Equipment  (Mobils 
and  field) 


50  Pneumatic  Equipment  (Air  compressors, 

pneumatic  motors,  ate.) 

51  Water  Purification  System 

52  Refrigeration  and  Air  Conditioning  Components 

53  Laundry  Equipmant 

54  Tentage,  Equippage,  and  Special  Purpose 

Clothing  Componants 

56  Pumps  (Excluda  angina  and  special  pumps). 

(See  group  2205  for  bilge  pumps) 

56  Filters.  Saparators,  and  Purifiers 

57  Spray  Equipmant  Components 

58  Sanitation  and  Fumigation  Equipmant 

Componants 

59  Water  Supply  Systems 

60  Steam  Boilers,  Water  Haatan,  Heating  Units, 

Burnan  (Exclude  haatars  in  groups  22,  23 
and  59) 

61  Gas  Generating  Equipmant  Comporwnts 

62  illuminating  Equipmant  (Other  than  elactrical) 

63  Control  Panais  and  Control  Compartments 

64  Ventilating  Fans  and  Blowers  (Special  purpoaa) 

66  Reproduction  Equipment  Componants 

67  Piacision  Instruments  and  Systems.  Mechanical 

Elactrical .  or  Electronic  (See  group  34  for 
fire  control) 

68  Warning,  Scanning,  and  Signaling  Davicat  and 

Navigational  Instruments  (Land,  air,  and 

water) 

60  Sawmill  Componants 

70  Machine  Toob  and  Ralatad  Equipment 

71  Snow  Removal,  Mowing,  and  Sweeping 

Equipmant  Componants 

72  Dispensing  and  Servicing  Eq'Jipmant  Componants 

73  Concrete  and  Asphalt  Equipmant  Comnonants 

(Mixers,  pavers,  pKaadan,  duct  coliactors, 
finishart,  etc.) 

74  Crane.  Shovafs,  and  Earth  Movmg  Equipmant 

Comfwnants 

76  Conveying.  Feeding.  Crushing.  Screening,  and 
Washing  Equipmant  Componants 

76  Fire  Fighting  Equipmant  Componants 

77  Musical  and  Tonal  Instruments 
60  Storage  Equipment  Components 

64  Nudaar  Componants  IFtimary  system) 

•5  Nuclear  Components  (Secondary  tyitam) 

66  Nuclear  Components  (System  eonpob  and 

instrumentation) 

67  Nudaar  Components  (Auxiliary  aqwpmant  and 

plant  accaasorws) 

60  Maintananca  and  Operating  Tuppliaa 

61  Chatmcai.  Biolo^,  and  Radwlogicai  (CBR) 

Equipmant 

66  General  Um  Standarduad  Farts 
to  Fans  Feauhar 
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Action  Step  2: 

Requirement 


Objective 


Procedures 


Develop  Generic  Equipment  List  by  Equipment  Identification  Code 


The  analyst  lists  all  equipment  identified  in 
Substep  1.3  according  to  the  EIC  structure 
developed  in  Action  Step  1. 


The  objective  of  this  substep  is  to  create  an 
equipment  configuration  that  mirrors  the 
functions  identified  in  Substep  1.3.  This 
equipment  structure  will  be  used  to  develop 
and  compare  equipment  structures  in  the 
substeps  which  follow. 


Substep  1.3  (Functional  Requirements 
Analysis)  provides  a  list  of  generic 
equipment  to  which  the  functional 
requirements  have  been  allocated.  The 
analyst  sorts  these  and  arranges  them  in  the 
appropriate  positions  in  the  EIC  structure. 

Some  equipment  may  be  able  to  satisfy  more 
than  one  function,  however,  only  one  will  be 
in  the  generic  equipment  structure. 
Conversely,  some  equipment  will  be  required 
by  the  generic  equipment  structure  that  is 
not  directly  related  to  the  functional 
requirements  but  is  implicit  in  the  nature  of 
the  type  of  system  identified. 

The  analyst  proceeds  by  levels  of  indenture. 
Once  a  generic  eq’upment  structure  is 
established  below  the  end-item  level,  the 
analyst  proceeds  to  the  next  level.  In 
consultation  with  the  Functional  Requirements 
analyst,  the  analyst  refines  the  descriptions 
of  generic  equipment  to  provide  the  greatest 
detail  possible. 
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Exampit 


The  generic  equipment  structure  will  support 
a  lover  level  of  indenture  as  more  decisions 
and/or  information  are  forthcoming.  As  the 
generic  equipment  structure  is  taken  to  a 
lover  level  of  indenture,  the  analyst  must  be 
careful  to  remain  general  in  definition  and 
not  specific  in  equipment  selection. 

For  instance,  "engine"  may  become  "engine, 
diesel"  and  even  "engine,  diesel, 
500-horsepower"  but  not  "engine,  diesel, 
Detroit  Diesel  Allison  8V71T."  The  choice  of 
specif ic' equipment  will  occur  in  Substeps 
1.5,  1.6,  and  1.7,  where  the  Predecssor,  BCS, 
and  Proposed  Systems,  respectively,  are 
established. 


Situation.  Functional  Requirements  Analysis 
has  established  the  new  system  must  be  a 
tracked  vehicle.  The  analyst  must  develop  a 
generic  equipment  structure  for  the  track 
functional  system  to  the  third  level  of 
indenture. 

Reaulta.  The  analyst  consults  TB  750-93-1 
and  obtains  the  following  results: 


EIC 


Description 


A 

A 

A 

A 

A 

A 

A 


13 

13 

01 

13 

02 

13 

03 

13 

04 

13 

05 

End  Item 

Track  System 

Suspension  Assembly 
Track  Support  Rollers  and 
Brackets 

Track  Idlers  and  Brackets 
Track  Drive  Sprockets 
Track  Assembly 
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Identify  Predecessor  System 


Overview 


Ob|tetlvt 


Input 


The  Mission  Area  Analysis  (MAA)  phase  of  the 
LCSMM  culminates  the  Army's  assessment  of  its 
mission  needs.  If  a  requirement  for  a  new 
weapon  system  emerges  from  the  MAA,  it 
results  from  perceived  deficiencies  in  the 
Predecessor  System,  a  system  currently  in  the 
Army  inventory. 

The  MAA  determines  whether  the  Predecessor 
System  should  be  replaced  completely  or  in 
part.  Replacement  of  the  Predecessor  is 
usually  advocated  in  the  event  of:  excessive 
operation  and/or  support  costs,  a  perceived 
enemy  threat  to  which  the  Predecessor  is 
unresponsive,  an  opportunity  to  incorporate 
technological  advances,  or  any  combination  of 
the  above. 

Three  types  of  system  acquisition  can  arise 
when  the  new  system  requirement  is  compared 
with  the  Predecessor  System.  These 
acquisiton  types  are  called  a  Replacement 
System,  a  System  Replacement,  or  a  New 
System.  The  distinctions  among  the  three 
types  are  important  because,  as  Table  1.5-1 
shows,  each  has  different  implications  for  a 
HARDMAN  application. 

The  objective  of  this  substep  is  to  identify 
the  weapon  system  (or  systems)  currently  in 
the  Army  inventory  which  will  be  replaced  by 
the  new  system.  The  currently  deployed 
system  is  termed  the  Predecessor  System. 


Input  from  previous  HARDMAN  substeps  includes 
a  list  of  system  functional  requirements  from 
Substep  1.3  (Determine  Functional 
Requirements).  Also  required  are  system 
descriptive  documents  such  as  the  Operational 
and  Organizational  Plan  (OSO)  and  the 
Required  Operational  Capability  (ROC). 


EXAMPLE 


>  Doctrinal  changa: 
Establish  amploynient 
doctrine 
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If  a  Predecessor  System  exists,  results  of 
this  substep  include  a  Predecessor  System 
equipment  structure.  This  equipment 
structure  incorporates  Equipment 
Identification  Codes  (EICs)  to  facilitate 
comparison  with  other  equipment 
configurations  in  the  analysis. 


A  Predecessor  System  is  identified  for  two 
reasons.  The  first  is  to  assist  the  HARDMAN 
analyst.  The  existence  of  a  Predecessor 
system  greatly  simplifies  the  analyst's  task 
in  Mission  and  Functional  Requirements 
Analysis,  as  the  Predecessor  System 
establishes  the  initial  operational  and 
organizational  context  for  the  new  system. 

The  Predecessor  System  is  also  the  physical 
embodiment  of  functions  matched  to  equipment. 
This  serves  as  a  reference  during  functional 
allocation. 

The  HARDMAN  analyst  also  uses  the  Predecessor 
System  equipment  in  developing  the  Baseline 
Comparison  System  (BCS).  Components  of  the 
BCS  may  be  drawn  from  the  Predecessor  System 
and  other  comparable  existing  systems  in  the 
DoD/NATO  inventories. 

The  degree  to  which  Predecessor  System 
components  are  incorporated  into  the  BCS 
depends  on  whether  the  developmental  system 
represents  a  Predecessor  upgrade  or  a  totally 
new  system.  In  a  Predecessor  upgrade,  some 
Predecessor  and  some  supplemental  components 
are  found  in  the  BCS.  In  a  development  with 
no  Predecessor,  the  BCS  is  derived  entirely 
from  other  systems  with  similar  components. 


The  second  reason  for  identifying  the 
Predecessor  System  is  to  identify  the 
quantity  and  quality  of  manpower,  personnel, 
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Action  Step 

Requiremtnt 


Objective 


Procedures 


and  training  (MPT)  resources  which  may  be 
available  to  support  the  requirements  of  the 
developmental  system.  Since  the  Predecessor 
System  is  currently  in  the  Army’s  inventory, 
it  has  MPT  resources  associated  with  it. 
These  resources  are  what  is  typically  termed 
the  "footprint"  within  which  the  MPT 
requirements  of  the  developmental  system  are 
often  required  to  fit. 

Figure  1.5-1  depicts  the  logic  flow  for 
identifying  the  Predecessor  System.  As  the 
figure  shows,  this  substep  entails  a  single 
action  step. 


The  analyst  identifies  the  weapon  system  or 
systems  in  the  Army  inventory  currently 
performing  the  functions  to  be  required  of 
the  Proposed  System. 


The  objective  of  this  action  step  is  to 
identify  a  currently  existing  system  which 
satisfies  a  majority  of  the  system  functional 
requirements. 


The  analyst  investigates  the  existence  of  a 
weapon  system  or  systems  which  satisfy  these 
two  criteria: 

Criterion  1.  The  system  must  currently  be 
in  the  Army  inventory  of  fielded  systems. 

Criterion  2.  The  functions  which  the 
system  performs  must  be  those  identified 
for  replacement  or  improvement  by  the 
developmental  system. 


Figure  1^1.  Logic  flow  for  Identify  Prodoentor  Syttom. 
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The  system  which  best  satisfies  both  criteria 
should  be  selected  as  the  Predecessor  System. 

The  analyst  can  often  identify  the 
Predecessor  System  from  the  Mission  Area 
Analysis  (MAA).  The  MAA  compares  the 
projected  mission  requirements  against  the 
ability  of  current  systems  to  satisfy  the 
requirements.  These  current  systems  are 
potential  Predecessor  Systems. 

Occasionally,  a  new  system  is  developed  to 
replace  more  than  one  current  system.  In 
this  case,  each  current  system  is  considered 
a  Predecessor  System  for  resource  comparison 
purposes;  the  MPT  requirements  of  the  new 
system  will  be  compared  to  each  current 
system  under  the  specific  organizational 
context  of  the  current  system.  In  developing 
the  BCS  and  Proposed  System  equipment 
structures,  the  components  of  all  current 
systems  are  examined  for  possible  inclusion. 

The  analyst  must  distinguish  between  the 
Predecessor  System  and  the  components  which 
comprise  it.  Only  the  Predecessor  System  is 
of  interest  to  the  HARDMAN  analyst  for 
resource  comparison  purposes,  while  any  and 
all  existing  components,  from  the  Predecessor 
System  or  other  weapon  systems,  may  be  used 
in  constructing  the  BCS  and  Proposed  System 
equipment  structures.  Even  if  no  system 
qualifies  as  a  Predecessor,  the  analyst  may 
use  components  from  the  rejected  candidates 
in  constructing  the  BCS  and  Proposed  System 
equipment  structures. 


Example 


Table  1.5-1  above  provides  examples  for  each 
acquisition  type  where  a  Predecessor  System 
is  involved. 


Substep  1.6/Ovefview _ 

Establish  Baseline  Comparison  System 


Overview  As  discussed  earlier,  the  HARDMAN 

methodology's  power  and  validity  are  derived 
primarily  from  its  use  of  comparability 
analysis.  A  HARDMAN  comparability  analysis 
is  performed  by  means  of  a  Baseline 
Comparability  System  (BCS),  as  required  by 
MIL-STD-1388-1A  (Logistics  Support  Analysis). 
The  BCS  is  not  intended  to  be  a  fully 
integrated  design.  Instead,  it  provides  a 
tool  for  comparability  analysis. 

The  BCS,  a  composite  of  similar  existing 
systems  and  subsystems,  is  developed  to 
resemble  the  Proposed  System.  Here, 

"similar"  means  that  BCS  components  (1) 
perform  functions  required  of  the  Proposed 
System  and  (2)  are  similar  in  design  to  the 
Proposed  System.  The  Proposed  System  design 
includes  conceptual  as  veil  as  existing 
features  of  the  desired  hardware,  software, 
and  mar  achine  interface  design. 

The  existing  systems  and  subsystems 
comprising  the  BCS  normally  reside  in  Army, 
DoD,  NATO,  or  civilian  inventories.  Criteria 
for  BCS  equipment  selection,  including  those 
stated  in  the  above  paragraph,  are  fully 
discussed  in  the  action  steps  below. 


Objectives  The  purpose  of  this  substep  is  twofold:  (1) 

to  establish  and  describe  a  BCS  for  use  in 
HARDMAN  comparabilty  analyses  and  (2)  to 
collect  BCS  HPT*related  data  which  will  be 
the  bases  of  new  system  HPT  requirements 
projections. 


Input  Input  from  earlier  HARDMAN  substeps  includes 

the  system  functional  requirements  developed 
in  Substep  1.3,  the  generic  equipment 
structure  generated  in  Substep  1.4,  and  the 
Predecessor  System  equipment  identified  in 
Substep  1.5.  In  most  cases,  some  information 
will  be  available  on  the  Proposed  System 
design,  whether  it  consists  of  design 
concepts,  preliminary  designs,  or  more 
detailed  designs. 
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Products 


Logic 


In  these  cases,  the  available  Proposed  System 
information  is  input  to  BCS  selection. 
Therefore,  Substep  1.7  (Establish  Proposed 
System)  may  begin  before  Substep  1.6  is 
completed.  Finally,  information  on  potential 
BCS  candidate  equipment  must  be  available  in 
order  to  make  BCS  equipment  selections. 


This  substep  produces  a  BCS  equipment  list 
(hardware  and  software)  for  use  in  equipment 
comparability  analyses  conducted  throughout 
the  remaining  HARDMAN  processes.  The 
equipment  must  be  specified  only  to  the  level 
of  detail  required  to  satisfy  the  study 
objectives.  This  substep  also  requires 
collection  of  MPT-related  data  for  all  BCS 
equipment . 


Figure  1.6-1  represents  the  logic  flow  for 
establishing  the  BCS.  As  shown  in  the 
figure,  four  action  steps  are  required  in 
this  substep.  The  first  three  action  steps 
correspond  to  the  application  of  three  BCS 
equipment  selection  criteria.  Note  that  the 
criteria  are  not  applied  to  the  BCS  as  a 
whole  but  ratRer  to  a  specific  item  of 
equipment  at  an  appropriate  level  of  . 
indenture  in  the  generic  equipment  structure. 

Typically,  HARDMAN  is  performed  at  the 
subsystem  level  of  indenture,  plus  or  minus 
one  level.  When  all  the  positions  in  the 
generic  equipment  structure  have  been 
assigned  to  an  item  of  equipment  that  has 
satisfied  the  BCS  selection  criteria,  then 
the  BCS  system-leve]  equipment  structure  has 
been  established. 

The  first  three  action  steps  are  of  equal 
importance  in  establishing  the  BCS  and  may  be 
performed  concurrently  rather  than 
sequentially.  Criteria  (Action  Steps)  i  and 
2  are  logical  requirements  of  the  HARDMAN 
methodology,  while  Criterion  3  is  a  practical 
requirement  for  generating  meaningful  HARDMAN 
products. 
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ACTION  STEPS 

Action  Step  1:  Apply  Functional  Criterion 

Requirements  In  Substep  1.3,  the  specific  new-system 

functions  required  to  perform  the  stated 
mission  were  determined.  Functional 
qualifiers,  or  performance  goals,  were 
defined  to  express  how  well  (how  accurately, 
how  quickly,  with  what  endurance,  etc.)  the 
functions  are  required  to  be  performed. 
Functional  requirements,  along  with  the 
performance  goals,  drive  the  Proposed  System 
design. 

Similarly,  functional  requirements  drive  the 
determination  of  the  BCS.  Functional 
capability  is  one  of  the  three  criteria  for 
BCS  equipment  selection.  BCS  equipment  must 
perform  new-system  functions.  However,  since 
the  BCS  only  contains  existing  systems  and 
subsystems,  BCS  equipment  will  not 
necessarily  meet  all  of  the  performance  goals 
established  for  the  Proposed  System. 


ObJfCtlvt  The  objective  of  this  step  is  to  insure  that 

BCS  equipment  performs  one  or  more  new  system 
functions  and  approach  new  system  performance 
requirements. 

Procedures  Action  Step  1  is  performed  for  every  HARDMAN 

application.  The  analyst  uses  the  system 
functional  requirements  and  the  generic 
equipment  list  as  input  for  this  procedure. 
The  analyst  uses  the  criterion  stated  below 
to  first  identify,  then  evaluate  the 
suitability  of  candidate  equipment  for 
inclusion  in  the  BCS. 

CrHerfon.  BCS  candidate  equipment  must 
satisfy  the  functional  requirements  of  the 
particular  position  in  the  generic  equipment 
structure  and  approach  or  meet  new  system 
performance  requirements. 
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The  analyst  first  uses  the  criterion  to 
identify  potential  BCS  candidate  equipment  in 
existing  Army,  DoD,  NATO,  and  civilian 
inventories*  If  a  Predecessor  System  exists, 
it  will  serve  as  a  potential  source  for  BCS 
candidate  equipment.  All  other  equipment 
identified  by  the  analyst  is  referred  to  as 
"supplemental  equipment."  Even  when  a 
Predecessor  exists,  the  BCS  as  a  system  is 
almost  invariably  a  combination  of 
Predecessor  and  supplemental  equipment. 

The  generic  equipment  list,  developed  from 
the  system  functional  requirements, 
identifies  the  types  of  equipment  required 
and/or  desired  to  perform  all  system 
functions.  Within  each  generic  equipment 
category,  several  specific  existing  pieces  of 
equipment  are  likely  to  be  identified. 

The  analyst  must  determine  which  of  the 
several  items  best  meets  the  performance 
requirements  specified  for  the  new  system. 
This  becomes  the  preferred  choice  for 
eventual  incorporation  into  the  BCS. 

However,  because  this  choice  may  not  satisfy 
the  remaining  BCS  selection  criteria,  it  is 
important  to  retain  for  further  consideration 
those  items  which  have  satisfied  the  strict 
functional  portion  of  the  criterion. 

As  a  practical  matter,  application  of  the 
functional  criterion  is  an  iterative  process. 
The  analyst  continually  refines  and  narrows 
his  list  of  potential  equipment  in  light  of 
functional  and  performance  information  that 
can  be  collected  on  each  item.  When  the 
range  of  functionally  suitable  items  has 
narrowed  to  manageable  proportions  (in  the 
analyst's  judgment),  the  second  portion  of 
the  criterion  may  be  applied  to  yield  the 
list  of  BCS  candidate  equipment.  Figure 
1.6-2  depicts  the  iterative  nature  of  the 
process. 


C/Substep  1.6 


System 

Functions 


Exampitt 
Example  1 


Generic 

Equipment 


I Predecessor 

^  - ►  Equipment 

Functional 
CriterJon?  — 

I  Supplemental 

- ►  Equipment 


BCS 

Candidate 


Figure  1.6-2.  Iterative  nature  of  functional 
criterion  application. 


Situation.  A  new,  advanced  attack  helicopter 
is  required  to  have  a  head-up  display  (HUD) 
which  provides  a  horizontal  view  of  the 
terrain  and  air  space  ahead  of  the  vehicle  as 
veil  as  70  to  80  degrees  to  either  side  of 
the  line  of  flight.  FLIR/EO/Radar  pickup  of 
potential  targets  and  friendly  vehicles 
and/or  equipment  will  be  superimposed  on  the 
horizontal  scene. 

IFF  intelligence  will  allow  labelling  of  the 
superimposed  objects  as  friendly,  unknown,  or 
enemy.  The  range  to  specific  enemy  targets 
can  be  added  to  the  display  by  operator/pilot 
request  through  an  an  interactive  keyboard. 
Table  1.6-1  summarizes  the  functions  and 
performance  requirements  of  the  subsystem. 
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Table  1.6-1,  HUD  Functional/Performance  Requirements 


Functional 


Performance 


Horizontal  sweep  view 


Superimpose  observed 
targets 

Accepts  multiple 
sensor  inputs 


Survey  terrain  and  airspace  70  to  80 
degrees  either  side  of  aircraft 

Ground  targets  (vehicles  and 
equipment),  air  targets 

Sensor  types:  Forward-looking  Infra¬ 
red  Radar  (FLIR),  Electro-optical 
(E-0),  conventional  radar 


Label  targets 


Identification,  friend  or  foe  (IFF) 
Range  to  target 
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Results.  Based  on  the  functional  and 

performance  requirements,  the  analyst 
identifies  the  following  candidates  for  the 

BCS: 

Table  1.6-2.  BCS  Candidates 

Head-Up  Display 

Description 

Nomenclature 

Used  on 

AN/AVQ-20 

Head-up  display  in  Air  Force  F-15 
fighter  serviced  by  computer  from 
multimode  radar  AN/APG-63  input; 
air-to-air  targets  only 

F-15 

Kaiser-built 

Display 

Head-up  display  in  Air  Force  F-16 
aircraK  serviced  by  Sperry  com¬ 
puter  from  AN/APG-66  radar  and 
television  (E-0)  inputs;  air-to-air 
only 

F-16 

AN/AVQ-28 

Head-up  display  in  F/A-18  serviced 
by  computer  from  multimode 

AN/APG-65  radar  set  and  AN/ASQ  173 
laser  detector/tracker/camera  set; 
has  range  capability,  look-down 
capability  for  ground  targets 

F/A-18 

Integrated  Helmet 
Display  Sight 
System 
(IHDSS) 

Head-up  similar  display  in 
helmet -mounted  monocle;  has  FLIP, 
E-0,  and  radar  images,  range  capa¬ 
bility,  air-to-ground  and  air- 
to-air  capability 

AH-64A 

C/Substep  1.6 


The  analyst  determines  that  the  candidate 
components  satisfy  the  functional  criteria  as 
follows: 


Table  1.6-3.  Functional  Criteria  Satisfied 


Head-up 

Horizontal 

Superimpose 

Accept 

Display 

Sweep 

Observed 

Multiple 

Label 

Nomenclature 

View 

Targets 

Input 

Targets 

AN/AVQ-20 

X 

X 

X. 

X 

Kaiser-built 

display 

X 

X 

X 

AN/AVQ-28 

X 

X 

X 

X 

iMDSS 

X 

X 

X 

X 

The  analyst  concludes  that  all  candidates 
except  the  Kaiser-built  model  satisfy  the 
requirement. 


Example 2  Situation.  Continuing  with  the  situation  in 

Example  1,  the  analyst  must  now  applry  the 
performance  portion  of  the  functional 
criteria. 
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Results.  The  analyst  obtains  the  following 
results: 

Table  1.6-4.  Applying  Performance  Criteria  to  BCS  Candidates 


Terrain 


After  applying  the  functional  criterion,  the 
analyst  concli:des  that  the  IHDSS  is  the 
preferred  candidate,  followed  closely  by  the 
AN/AVC-28. 


Action  Step  2:  Apply  Similarity  Criterion 
Requirements  if  Proposed  Syste 


If  Proposed  System  alternatives  are 
available,  it  is  important  for  BCS  equipment 
to  resemble  the  Proposed  System's  design  as 
closely  as  possible.  Specific  and  detailed 
Proposed  System  alternatives  are  valuable  to 
the  HARDMAN  analyst  because  they  are  presumed 
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Obltcllvt 


Proctdyits 


to  be  the  result  of  thorough  technical  and 
engineering  investigations  by  materiel 
contractors*  The  effort  required  is 
considerably  more  than  the  HARDMAN  analyst 
can  typically  afford. 

Moreover,  materiel  contractors  are  presumed 
to  have  provided  integrated  solutions  to  the 
system  requirements  stipulated  by  the  Army. 

It  is  these  solutions  which  are  being 
"proposed”  to  the  Arm^  for  acquisition.  To 
best  assist  the  Army  in  deciding  among  the 
various  Proposed  System  alternatives  or  to 
fairly  evaluate  the  technical  merits  of  a 
single  Proposed  System  alternative,  the  BCS 
should  reflect  the  technology  incorporated  by 
the  alternatives  at  hand. 


The  objective  of  this  action  step  is  to 
insure  that  the  BCS  candidate  equipment 
identified  previously  is  similar  in  design  to 
available  Proposed  System  alternatives* 


The  analyst  uses  the  following  criterion  to 
evaluate  the  BCS  candidate  equipment 
identified  in  the  previous  Action  Step. 

Crlterfon.  The  preferrc^^d  BCS  equipment  is 
that  most  similar  in  design  to  available 
Proposed  System  alternatives.  "Design* 
refers  to  the  hardware,  software,  and 
man-machine  interface  aspects  of  the  system 
under  analysis.  Similarity  should  be  judged 
by  the  best  overall  combination  of  the 
following  factors: 

-weight 

-volume 

-layout/arrangement  of  component  parts 
-type  of  technology  incorporated 
-sophistication  of  technology 
incorporated 

-environment  (e.g.,  ground  vs.  air) 
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Additional  information,  such  as  support 
system  characteristics  and  force  structure 
considerations,  may  also  be  used  by  the 
analyst,  although  that  information  is  less 
important.  Thus,  this  action  step  requires 
the  collection  of  information  on  BCS 
candidate  equipment  hardvare/sof tvare  design 
and  operational,  organizational,  and  support 
system  features. 


Example  Situation.  Three  materiel  contractors  have 

responded  to  the  Army's  requirement  for  a  new 
attack  helicopter.  For  the  HUD  system,  only 
one  of  the  contractors  has  included  the 
capability  to  accept  PLIR  input.  All  three 
proposed  HUD  subsystems  accept  conventional 
radar  and  electro-optical  input. 

Result  The  analyst  concludes  that  the  IDHSS 
is  preferred  on  the  basis  of  the  similarity 
criterion.  Since  the  IDHSS  accepts  all  three 
inputs,  it  is  most  similar  to  the  ideal 
Proposed  System  which  meets  all  of  the 
functional  and  performance  requirements.  No 
other  alternatives  meet  all  of  the 
requirements. 


Action  Step  3:  Apply  Oafs  Criterion 


Requirements  As  a  practical  concern,  sufficient  data 

describing  BCS  equipment  must  be  available 
for  (1)  performance  of  comparability  analyses 
and  (2)  generation  of  Proposed  System  KPT 
information.  The  quantity  and  quality  of 
data  available  for  the  BCS  candidate 
equipment  will  be  considered  in  this  action 
step. 


% 

Objective  The  objective  of  this  action  step  is  to 

insure  that  BCS  candidate  equipment  has 
sufficient  and  sufficiently  mature  data 
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Procedurtt 


The  analyst  uses  the  criterion  stated  belov 
to  evaluate  the  BCS  candidate  equipment 
identified  previously. 

Criterion.  The  preferred  BCS  equipment  has 
sufficient  and  sufficiently  mature  data 
available.  Sufficiency  should  be  judged  in 
terms  of  the  extent  to  which  the  following 
data  elements  are  available  for  each  BCS 
candidate  equipment: 


•  Equipment  usage  rates 

•  Mean  duration  of  usage 

•  Frequency  of  failure 

•  Frequency  of  maintenance  actions, 
both  corrective  and  preventive 

•  Effect  of  failure 

•  Task  descriptions  for  both 
operation  and  maintenance  tasks 

•  Task  times,  elapsed  and  total 

•  Task  time  allowance  (e.g.,  pro¬ 
ductivity,  make- ready /put  away)  • 

•  Task  frequencies,  inherent 
and  induced 

•  MOS/skill  level  performing  tasks 

•  Humber  of  personnel 
performing  tasks 

e  Maintenance  level  for 
maintenance  tasks 
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Action  Step  4:  Select  Preferred  BCS  Equipment 


Rtquirtmtntt  This  action  step  summarizes  the  results  of 

the  criteria  applied  in  the  previous  action 
steps. 


Obltcthra  The  objective  of  this  action  step  is  to 

establish  the  BCS  Equipment  Structure.  This 
structure  is  the  result  of  replacing  items 
from  the  generic  equipment  structure  with  the 
BCS  equipment  which  bests  satisfies  the 
criteria  previously  applied. 


Proctdurta  The  analyst  selects  from  the  list  of  BCS 

candidates  the  item  which,  in  his  judgment, 
best  meets  the  functional,  similarity,  and 
data  criteria.  This  item  is  entered  in  the 
appropriate  position  in  the  equipment 
structure.  Data  and  other  information  on  the 
candidates  not  selected  are  retained  for 
potential  use  in  tradeoff  analyses. 

The  analyst  repeats  the  entire  selection 
process  for  each  EIC  in  the  generic  equipment 
structure.  When  each  EIC  has  been  assigned 
an  item  which  has  satisfied  the  BCS  select  ion 
criteria,  the  BCS  Equipment  Structure  has 
been  completed. 


Eiample  Based  on  the  results  of  all  previous 

examples,  the  analyst  ranks  the  BCS 
candidates  as  follows: 


1.  AN/AVQ-28 

2.  AN/AVQ-20 

3.  Kaiser-built  for  P-16 

4.  IHDSS 
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The  lack  of  data  excludes  the  IHDSS  from 
consideration  as  a  BCS  candidate,  although  it 
may  be  used  in  a  tradeoff.  The  Kaiser-built 
model  and  the  AN/AVQ-20  satisfy  the  data 
criterion  equally,  but  the  AN/AVQ-28  is 
preferred  because  it  satisfies  more 
functional/performance  requirements . 
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Substep  1  J/Overview 

Establish  Proposed  System 


Overview  The  Proposed  System  is  an  analytical 

construct  developed  to  represent  the  best 
estimate  of  the  design  of  the  new  system.  As 
with  the  BCS,  the  Proposed  System  is 
developed  by  identifying  specific  hardware 
components  which  perform  system-level 
functions  and  tasks  and  is  expected  to 
fulfill  all  system  functional  requirements. 

Unlike  the  BCS,  however,  the  Proposed  System 
is  expected  to  meet  all  goals  with  respect  to 
how  well  system  functions  are  performed.  To 
satisfy  this  expectation,  the  Proposed  System 
may  incorporate  technological  advances  likely 
to  exist  before  the  system's  projected 
Initial  Operational  Capability  date. 

These  technological  advances  may  not  be 
mature  in  the  sense  of  capabilities 
demonstrated  by  actual  performance  in  the 
field.  Accordingly,  data  associated  with  tne 
components  of  the  Proposed  System  need  not  be 
mature.  They  may  come  from  less  empirical 
sources  such  as  laboratory  tests  or 
engineering  estimates. 

This  technological  immaturity  is  also  unlike 
the  BCS,  where,  to  qualify  for  inclusion,  a 
component  had  to  have  mature,  empirical  field 
data  available.  The  maturity  of  data  used 
for  the  BCS  and  the  Proposed  Systems  forms  a 
crucial  distinction  between  the  two  systems. 

When  analysis  begins,  one  or  more  Proposed 
Systems  may  already  be  available.  Typically, 
the  number  of  Proposed  Systems  reflects  the 
number  of  major  technological  approaches 
bein^  considered  (e.g.,  a  gun  design  versus  a 
missile  design)  or  the  number  of  unique 
design  solutions  offered  by  competing 
materiel  contractors  in  response  to  a 
preliminary  statement  of  mission  need  or 
system  requirement  by  the  Army. 
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Each  Proposed  System  may  either  be  an  actual 
design  obtained  directly  from  a  contractor  or 
a  conceptual  design  developed  by  the  HARDMAN 
analyst.  In  the  latter  case,  the  conceptual 
design  will  include  technological  advances 
and/or  new  operating  and  support  concepts 
which  are  likely  to  be  incorporated  in  the 
eventual  Proposed  System  design  to  be 
fielded. 

Establishing  a  conceptual  Proposed  System  is 
required  when  contractor  designs  are  not 
available.  Lack  of  design  availability  is 
typical  during  the  early  phases  of  the 
acquisition  process.  As  the  acquisition 
progresses,  the  conceptual  design  is  replaced 
by  the  actual  designs  being  proposed  by 
contractors.  When  contractor-provided 
designs  are  available  but  incomplete,  a 
combination  of  the  two  approaches  is  used. 


Objective  The  purpose  of  this  substep  is  to  establish 

and  describe  the  Proposed  System  alternatives 
for  use  in  HARDMAN  comparability  analyses. 


Input  Input  from  earlier  HARDMAN  substeps  includes 

the  operational  and  support  concepts  for  the 
Proposed  System  from  Substeps  1.1  and  1.2, 
the  system  functional  requirements  developed 
in  Substep  1.3,  and  the  BCS  equipment  list 
generated  by  Substep  1.6.  For  cases  in  which 
actual  proposed  designs  have  been  completed, 
this  information  is  an  important  input  to 
Substep  1.7. 

Finally,  to  establish  conceptual  designs  for 
all  or  part  of  the  new  system,  information  on 
Proposed  System  design  concepts  and 
applicable  new  technologies  must  be  collected 
for  this  substep. 
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Products  This  substep  produces  a  Proposed  SysteAi 

equipment  list  for  use  in  equipment 
comparability  analyses  conducted  throughout 
the  remaining  HARDMAN  processes.  The 
equipment  must  be  specified  only  to  the  level 
of  detail  required  to  satisfy  the  study 
objectives. 


Logic  Figure  1.7-1  represents  the  logic  flow  for 

establishing  the  Proposed  System. 

As  shown  in  the  figure,  four  action  steps  are 
required  in  this  substep.  Action  Step  1 
considers  proposed  designs  which  actually 
exist.  Proposed  System  actual  designs  may  or 
may  not  be  complete. 

Action  Steps  2,  3,  and  4  generate  Proposed 
System  components  which  may  be  used  to 
complete  actual  proposed  designs  which  are 
incomplete  or  to  develop  a  Proposed  System 
alternative  on  a  component-by-component 
basis.  When  all  positions,  or  EICs,  in  the 
generic  equipment  structure  have  been 
assigned  an  item  of  Proposed  System 
equipment,  the  Proposed  system-level 
equipment  structure  has  been  established. 


Action  Steps 


Act/on  Step  1:  Obtain  Proposed  System  Designs  [Actual] 


Requirements  Establishing  the  Proposed  System(s)  may  be  an 

easy  exercise  if  detailed,  complete 
contractor  designs  of  the  new  system  exist. 
Contractor  designs  may  simply  serve  as 
alternative  Proposed  System  designs. 

However,  in  early  applications  of  the  HARDMAN 
methodology,  actual  designs  are  commonly 
unavailable  or  incomplete.  The  analyst  must 
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Figure  1.7-1.  Establish  Proposed  System  logic 
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Oblectlvf 


Procedures 


either  identify  existing  Proposed  System 
design  information,  if  any,  or  develop  system 
components  in  Action  Steps  2,  3,  and  4. 


The  objective  of  this  action  step  is  to 
identify  available  actual  designs  of  Proposed 
System  components  for  inclusion  in  the 
HARDMAN  Proposed  System  configuration. 


Action  Step  1  will  be  performed  only  if 
actual  new  system  designs  are  available.  For 
HARDMAN  applications  early  in  an  acquisition, 
actual  design  information  is  not  likely  to 
exist. 

1.  The  analy; ^  must  determine  the  existence 
of  and  collect  design  information  for 
available  proposed  subsystems  and  equipment. 
Sources  of  such  design  information  may 
include  contractor  proposals,  drawings  and 
other  design  documents,  mock-ups,  equipment 
prototypes,  etc.  Design  information  must  be 
documented  to  the  level  of  detail  required  to 
support  comparability  analyses  with  the  BCS. 

2.  The  analyst  insures  that  the  actual 
designs  of  the  Proposed  System  components 
adhere  to  Proposed  System  operational  and 
support  concepts,  and  notes  where  deviations 
occur. 

3.  The  analyst  determines  what  new  system 
functional  and  performance  requirements  are 
satisfied  by  the  actual  Proposed  System 
component  designs. 

4.  The  analyst  determines  the  specific  BCS 
equipment  and  the  generic  equipment  to  which 
each  actual  Proposed  System  component  design 
corresponds. 
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Example  Situation.  The  new  system  is  to  be  a  very 

high  frequency,  frequency  modulated  (VHF-FM) 
radio.  Generic  and  BCS  equipment  has  been 
identified  as  follows: 


Generic  Equipment 


BCS  Equipment 


Receiver /Transmit ter 
Antenna  coupler 
Whip  antenna 
Vehicular  antenna 
RF  amplifier 
Battery 


AN/ARC-114 

CU2041/AR 

AT-892/PRC-25 

AT-1095/VRC 

AM6176/VRC 

BA-4386/U 


The  XYZ  Corporation,  a  materiel  contractor, 
has  submitted  a  proposal  to  satisfy  the 
requirement  for  the  new  radio.  All  of  the 
equipment  is  of  new  design.  The  contractor's 
proposed  configuration  is  as  follows: 


Name 


Description 


Basic  unit 


Vehicular  antenna 

Portable  antenna 


Receiver/transmitter,  RF 
amplifier,  and  battery 
in  one  self-controlled 
unit 

Antenna  and  integral 
coupler 

Whip  antenna  and  integral 
coupler 


Results.  The  analyst  examines  the 
descriptive  data  and  specifications  in  the 
XYZ  proposal.  Two  conclusions  are  reached: 

(1)  the  contractor  equipment  appears  to  meet 
the  new  system  functional  requirements  and 

(2)  the  data  are  sufficient  to  support 
further  analyses.  The  analyst  accepts  the 
XYZ  equipment  as  a  Proposed  System 
alternative. 
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Action  Step  2:  Determine  BCS  Performance  Deficiencies 


Requirements  To  complete  the  Proposed  System  design,  the 

engineering  analyst  must  project  a  conceptual 
design  of  system  components  for  which  an 
actual  design  does  not  yet  exist.  The  basis 
from  which  to  make  this  projection  is  the  BCS 
equipment  configuration  and  the  deficiencies 
in  BCS  functional  capabilities  as  compared  to 
new  system  performance  requirements. 


Objective  The  objective  of  this  action  step  is  to 

identify  the  functional  deficiencies  of  BCS 
components  for  which  conceptual  designs  must 
be  projected. 


Procedures  Action  step  2  will  be  performed  unless  the 

entire  Proposed  System  was  developed  in 
Action  Step  1. 

1.  The  analyst  selects  an  EIC  and  identifies 
new  system  functional  and  performance 
requirements  which  may  not  be  satisfied  by 
the  Proposed  System  components  identified 
thus  far. 

2.  For  the  corresponding  EIC  in  the  BCS 
equipment  structure,  the  analyst  identifies 
BCS  equipment. 

3.  The  analyst  matches  the  new  system 
functional  and  performance  requirements  from 
Procedure  1  with  the  BCS  equipment  from 
Procedure  2.  The  analyst  identifies  the  BCS 
performance  shortfalls.  These  shortfalls 
should  be  readily  available  from  application 
of  the  BCS  selection  criteria  in  Substep  1.6 
(Establish  BCS). 


C/Substep  1.7 


Example  Situation.  The  situation  of  the  first 

example  is  continued  here.  The  XYZ 
Corporation  has  withdrawn  its  proposal.  The 
analyst  must  develop  a  Proposed  System 
alternative.  The  first  step  involves 
investigating  the  performance  deficiencies  of 
the  BCS.  The  analyst  begins  with  the 
receiver/transmitter . 

Results.  Through  research  and  engineering 
judgment,  the  analyst  obtains  the  following 
results: 


Generic 

Equipment 

BCS 

Equipment 

BCS  Performance 
Deficiencies 

UHF 

Receiver/ 

transmitter 

AN/ARC-614 

— Slow  rate  of 
frequency 
selection 
— Manual  control 
— Few  preset 
channels 
— No  digital 
frequency 
readout 

Action  Step  3:  Incorporate  New  Technologies 


Requirements  The  Proposed  System  design  must  overcome  the 

BCS  performance  deficiencies  identified  in 
Action  Step  2.  Action  Step  3  generates  a 
Proposed  System  conceptual  design  by 
identifying  technological  improvements  to  the 
BCS  which  permit  the  new  system  to  achieve 
its  functional  and  performance  requirements. 


Ob|tetlvt  The  objective  of  this  step  is  to  identify  and 

document  technological  improvements  to  the 
BCS  design  which  overcome  the  BCS  performance 
deficiencies  identified  in  the  previous 
action  step. 


Procedurtt 
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Action  Step  3  is  performed  if  Action  Step  2 
identifies  BCS  performance  deficiencies. 

1.  The  analyst  identifies  and  analyzes  new 
technologies  which  may  provide  design 
solutions  to  the  BCS  performance  deficiencies 
identified  in  Action  Step  2.  To  be 
considered,  such  new  technologies  must  be 
available  at  the  time  the  new  system  is  to  be 
fielded.  The  two  major  sources  of 
information  on  new  technologies  are  (1) 
equipment-related  literature  and  documents 
and  (2)  interviews  with  subject-matter 
experts. 

2.  New  technologies  which  represent  the  most 
likely  design  improvements  to  the  BCS  design 
are  selected  for  the  Proposed  System  design. 
The  technological  improvements  are 
incorporated  into  BCS  equipment  designs, 
yielding  conceptual  designs  for  corresponding 
Proposed  System  equipment.  Alternatively, 
the  technological  improvements  may  be 
embodied  in  equipment  which  replaces,  rather 
than  updates  or  modifies,  BCS  equipment. 
Technological  improvements  are  documented  in 
the  Design  Difference  Index  (see  Substep  1.8, 
Determine  Design  Differences). 

3.  Thus,  the  Proposed  System  conceptual 
srquipment  is  a  function  of  the  BCS  equipment 
and  new  technology: 


BCS  New 

Equipment  ^  Technologies 


Proposed 

System 

Equipment 
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Example  Situation.  The  situation  of  the  previous 

examples  is  continued. 

Results.  The  analyst  researches  the  new 
technologies  likely  to  be  available  to 
overcome  the  BCS  performance  deficiencies. 
The  following  results  are  obtained; 


BCS  Performance 
Deficiency 


Potential 

Technology  Improvement 


— Slow  rate  of  — Increase  response  with  large 

frequency  selection  or  very  large  scale  integrated 

circuits  (LSI/VLSI ) 


J 

— Manual  control 

— Automatic  control  provided  by 
LSI/VLSI  with  microprocessor 

— Few  preset 

— More  preset  channels  with 

*  . 

channels 

mass  memory 

— No  digital 
frequency 
readout 

— Existing  technology 
add  readout 

Action  Step  4:  Determine  Proposed  System  Designs 


Requirements 


Objective 


The  analyst  must  combine  the  conceptual 
Proposed  System  components  with  those 
actually  available  to  complete  the 
development  of  the  Proposed  System. 


The  objective  of  this  action  step  is  to 
complete  development  of  the  Proposed  System. 


Performance  of  Action  Step  4  follows  Action 
Steps  2  and  3  and,  by  complementing  the 
results  of  Action  Step  1,  completes  the 
HARDMAN  Proposed  System. 


Procedures 
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ExampI* 


1.  The  analyst  repeats  Action  Steps  2  and  3 
for  each  EIC. 


2.  The  actual  and  conceptual  Proposed  System 
equipment  which  results  from  Action  Steps  1 
thru  3  is  combined  to  produce  an  equipment 
structure  for  a  Proposed  System  alternative: 


Proposed 
System  > 
Actual 
Designs 


Proposed 

System 

Conceptual 

Designs 


HARDMAN 

Proposed 

System 


3.  The  analyst  applies  Proposed  System 
operational  and  support  concepts  to  the 
Proposed  System  equipment  structure  to  insure 
a  reasonable  level  of  system  integration. 

4.  The  analyst  repeats  Action  Steps  1 
through  4  for  each  Proposed  System 
alternative. 


If  the  XYZ  Corporation  had  not  withdrawn,  its 
R/T  unit  would  have  been  accepted  as  the 
Proposed  System  alternative.  The  analyst 
would  then  have  proceeded  to  an  examination 
of  the  design  differences  in  Substep  1.8 
(Determine  Design  Differences). 

The  Proposed  System  R/T  unit  developed  by  the 
analyst  is  the  AN/ARC*144,  which  incorporates 
the  technological  improvements  identified  in 
Action  Step  3.  These  improvements  also  form 
the  basis  for  the  design  differences. 


This  page  intentionally  left  blank. 
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Determine  Design  Differences 


Objectives 


Input 


Products 


Previous  substeps  have  established  the 
equipment  structures  for  the  BCS  and  all 
Proposed  System  alternatives.  The  first 
objective  of  this  substep  is  to  determine 
diHerences  between  the  BCS  and  each  Proposed 
System  alternative.  Design  differences  are 
sought  in  terms  of  the  specific  equipment  or 
technology  that  is  incorporated  in  the 
Proposed  System  in  order  to  meet  the 
functional  requirements  of  the  new  system. 

The  second  objective  is  to  estimate  what 
effect,  or  impact,  these  differences  are 
likely  to  have  on  the  data  elements  and 
parameters  which  will  be  used  to  compute  the 
system's  manpower,  personnel,  and  training 
(MPT)  requirements  in  subsequent  substeps. 
Action  Step  2  addresses  this  issue. 


Input  from  earlier  HARDMAN  substeps  includes 
the  BCS  equipment  list  as  well  as 
descriptions  and  specifications  of  each  BCS 
component  from  Substep  1.6.  Substep  1.7 
contributes  an  equipment  list  for  each 
Proposed  System  alternative,  descriptions  and 
specifications  for  actual  Proposed  SYstem 
components,  and  descriptive  information  on 
the  technological  improvements  incorporated 
into  conceptual  Proposed  System  components. 


The  output  of  this  substep  is  a 
quantification  of  the  design  differences 
tetween  the  BCS  and  each  Proposed  System 
alternative.  Design  differences  are  arrayed 
in  a  Design  Difference  Index  (DDI),  which 
supports  extrapolation  of  BCS  data.  A 
separate  DDI  is  constructed  for  each 
BCS/Proposed  System  comparison,  i.e.,  one  for 
each  Proposed  System  alternative.  Table 
1.6-1  provides  a  sample  Design  Difference 
Index. 


o  Design  Difference  index  (DDi) 


m 

i 
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BCS  data  extrapolations  are  performed  in 
Substep  1.9  (Determine  R&M  Requirements)  and 
subsequent  substeps.  Results  are  used  to 
fill  gaps  in  Proposed  System  reliability, 
maintainability  (R&M),  and  other  performance 
data. 


Logic  A  comparison  of  BCS  and  Proposed  System 

equipment  results  in  identifying  differences 
both  in  configuration  and  in  the  type  of 
technology  employed  in  each.  The  design 
differences  form  the  rationale  for 
perturbation  of  reliability,  maintainability, 
and  other  data  from  the  BCS  to  estimate 
values  for  the  same  data  elements  in  the 
Proposed  System.  Quantification  of  the 
design  difference  impacts  is  the  factor  which 
affects  determination  of  the  BCS  and  Proposed 
System  alternatives*  MPT  resource 
requirements  in  later  substeps. 

Figure  1.8-1  depicts  the  logic  flow  for 
determining  design  differences.  As  the 
figure  shows,  Subsl ^p  1.8  entails  two  action 
steps.  This  substep  is  repeated  for  each 
BCS/Proposed  System  comparison. 


Action  Steps 


Action  Step  1:  Identify  and  Categorize  Design  Differences 


The  analyst  identifies  design  differences 
between  the  BCS  and  the  Proposed  System  and 
categorizes  them  as  differences  in 
configuration  and/or  in  technology  employed. 


Requirements 


C/Substep  1.8 


Objective 


Procedures 


The  objective  of  this  action  step  is  to 
determine  the  nature  of  the  design 
differences  between  the  BCS  and  Proposed 
System  alternative. 


1.  The  analyst  selects  BCS  and  Proposed 
System  equipment  from  one  ElCr  then  compares 
the  Proposed  System  equipment  to  that  of  the 
BCS.  Differences  in  configuration  between 
the  two  are  classified  as  follows: 


When  compared  to  the  BCS,  the  Proposed  System 
equipment  is: 

Classified 

as  If 


Addi t ion  Subsystems/components/ 

assemblies/parts  have  been 
added  to  those  of  the  BCS 


Delet ion  Subsystems/components/ 

assemblies/parts  have  been 
deleted  from  the  BCS 


Replacement  Proposed  System  equipment 

has  wholly  replaced  BCC 
equipment 


Modifica¬ 
tion/Im¬ 
provement 
No  change 


Proposed  System  equipment 
is  a  modified/improved 
version  of  BCS  equipment 
BCS  and  Proposed  System 
equipment  is  the  same 


Note  that  combinations  of  categories  can 
exist.  In  other  words,  deletion  of  some 
components  may  be  possible  if  the  ones  that 
remain  are  modified  and/or  improved. 

2.  For  cases  where  the  comparison  results  in 
a  replacement  or  a  modification/ improvement, 
the  analyst  determines  the  nature  of  the 
technology  that  will  be  (1)  in  the  Proposed 
System  equipment  which  is  replacing  the  BCS 
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equipment  or  (2)  incorporated  into  the  BCS  by 
modi f icat ion/ improvement .  The  analyst  must 
exercise  professional  judgment  in  determining 
the  nature  of  those  differences.  Table  1.8-2 
lists  some  of  the  factors  to  be  considered. 

Table  1.8-2.  Design  Difference  Considerations 


Factor 

Physical 

Features 

Location 


Electrical 

Design 


Mechanical 

Design 


Special 

Tools/Test 

Equipment 


Elements 

Size,  weight,  volume,  number 
of  units 

Concentration  vs.  dispersion 
of  the  components/assemblies 
on  the  system 

Digital  vs.  analog,  level  of 
internal  functional  integra¬ 
tion,  degree  of  modularity, 
miniaturization,  accessi¬ 
bility 

Accessibility,  complexity  of 
major  moving  assemblies, 
tolerances 

Degree  to  which 
they  are  required 


Bu?'’"-In/  Degree  to  which  BITE/PITE  is 

.xug^'ln  present,  degree  to  which  it 

Test  Equip-  covers  all  components  or 
ment  only  selected  ones 

(BITE/PITE) 

Software  Compatibility  between/among 

subsystems,  degree  to  which 
software  aids  and/or  re¬ 
places  human  performance 

System  Sharing  controls  and  dis- 

Integra-  plays  for  several  functions, 

tion  number  of  interconnections, 

extent  to  which  a  bus  exists, 
type  of  bus 
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3.  In  the  appropriate  DDI  columns,  the 
analyst  records  the  EIC,  the  nomenclature  of 
the  BCS  and  Proposed  System  equipment,  the 
design  differences,  and  the  source  of  the 
information  used  to  determine  the  design 
differences.  Assigning  change  numbers  may 
also  facilitate  retrieving  the  information 
later  in  the  analysis.  Close  attention 
should  be  paid  to  describing  the  nature  of 
the  technological  differences;  shorthand  or 
highly  subjective  terms  are  acceptable  if 
adequately  explained. 


Example  Table  1.8-3  provides  an  example  of  a  DDI  with 

design  difference  information  recorded. 


Action  Step  2:  Estimate  Impacts  of  Design  Differences 

Requirements  The  analyst  determines  whether  estimates  of 

reliability,  maintainability,  and  task 
performance  data  are  available  for  the 
Proposed  System  equipment.  If  data  are  not 
available,  the  analyst  must  estimate  the 
quantitative  effect,  or  impact,  the  design 
differences  identified  in  Action  Step  1  will 
have  on  BCS  RfcM  and  task  performance  data. 


Objective  The  objective  of  this  action  step  is  to 

estimate  the  quantitative  effect  of  the 
design  differences  identified  in  the  previous 
action  step. 


Procedures  1.  The  analyst  determines  the  availability 

of  MM  and  task  performance  data  for  Proposed 
System  equipment.  Ideally,  data  elements  are 
available  at  the  greatest  level  of  detail  — 
task  time  and  task  frequency  for  operator  and 
maintainer  tasks*  However,  the  procedures 
may  be  applied  to  more  summary  parameters 
such  as  the  maintenance  ratio  (MR). 
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Sources  of  such  data  include  materiel 
contractor  proposals,  drawings,  and  other 
design  documents;  equipment  prototypes  and 
mock-ups;  and  the  Logistics  Support  Analysis 
Record  (LSAR),  especially  for  systems  in  the 
later  phases  of  the  acquisition  process. 
Preliminary  results  from  Sample  Data 
Collection,  Development,  and/or  Operational 
Tests  may  also  be  considered,  especially  if 
the  results  are  sufficient  to  provide 
estimates  of  task  time  and  frequency  but  do 
not  satisfy  selection  criteria  for  the  BCS. 

If  actual  Proposed  Systems  exist  (see  Substep 
1.7,  Action  Step  1/,  or  if  the  design 
difference  for  the  EIC  under  analysis  is  an 
addition  or  replacement,  the  analyst  should 
make  every  effort  to  obtain  values  for  the 
RfiiM  and  task  performance  parameters. 

2.  If  data  are  not  available,  the  analyst 
determines  whether  design  differences 
identified  in  Action  Step  1  will  affect  any 
of  the  parameters  of  concern  —  operator  and 
maintainer  task  time  and  frequency  —  or  more 
summary  parameters. 

3.  For  the  parameters  affected,  the  analyst 
must  estimate  a  perturbation  value  (PV).  A 
PV  is  used  to  adjust  the  values  of  the  BCS 
parameters  to  estimate  parameter  values  for 
the  Proposed  System.  A  PV  must  have  both 
magnitude  and  direction.  That  is,  it  must 
increase  or  decrease  the  BCS  values  to  the 
limit  indicated  by  the  specific  nature  of  the 
design  difference. 

The  analyst  must  judge  both  the  magnitude  and 
the  direction  of  the  PV  based  on  the  design 
differences,  neither  may  be  readily  apparent 
to  the  analyst.  Experience  has  shown  that 
both  factors  are  affected  by  the  particular 
area  of  technology  under  consideration. 
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For  example,  in  electronics  a  decrease  of  30 
percent  in  maintenance  task  times  may  be 
reasonable,  given  the  advances  made  in 
miniaturization  and  modularity.  An 
improvement  of  that  magnitude  may  be  harder 
to  account  for  in  automotive  components. 

To  the  extent  permitted  by  the  study’s  scope 
the  analyst  should  consult  with  experts  in 
the  technology  area.  Multiple  opinions  on 
the  magnitude  and  direction  of  the  PVs  are 
more  useful  (and  easier  to  defend)  than 
single  estimates. 

As  a  general  rule,  PVs  of  10  percent  or  less 
represent  low  risk  improvements;  11  to  30 
percent,  medium  risk;  and  over  30  percent, 
high  risk.  The  more  risk  involved,  the  more 
attention  the  analyst  should  devote  to 
securing  a  consensus  from  subject-matter 
experts  not  involved  in  the  HARDMAN 
application. 

4.  The  analyst  now  quantifies  the  impact  of 
the  design  differences: 


Where  Proposed  System  data  is  available, 
the  impact  is  the  result  of  subtracting 
the  BCS  values  from  the  Proposed  System 
values: 


Proposed 

System 

Values 


BCS 

-  Values  = 


Design 

Difference 

Impact 


If  Proposed  System  data  is  not  available, 
the  impact  is  the  product  of  the  BCS 
values  and  the  PV,  provided  the  PV  is 
expressed  as  a  decimal  which  equals  the 
percent  change  and  has  a  positive  or 
negative  value  to  indicate  the  direction 
of  change: 


BCS 

Values 


Design 

Difference 


pac 
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Proposed  System  values  are  always  the  sum  of 
the  BCS  values  and  the  quantitative  impact  of 
the  design  differences. 

5.  If  a  PV  is  obtained,  the  analyst  records 
the  PV  in  the  appropriate  column  on  the  DDI. 
If  data  are  available  for  the  Proposed 
System,  then  both  the  BCS  and  the  Proposed 
System  values  should  be  reflected  in  the 
Remarks  column.  The  PV  column  is  left  blank. 

6.  Even  if  Proposed  System  data  are 
available,  the  analyst  should  estimate  PVs 
for  the  EIC  under  analysis  as  veil  as  obtain 
the  design  difference  impact  by  subtraction. 
Both  methods  may  be  applied  if  warranted  by 
the  scope  of  the  analysis.  When  both  methods 
are  employed,  PVs  provide  a  useful  check  on 
the  Proposed  System  values  provided  by 
materiel  contractors. 


The  situation  of  the  previous  example  is 
continued.  Table  1.8-4  shows  a  DDI  with  the 
impact  of  design  differences  recorded.  Note 
that  the  PV  is  positive  because  it  is  applied 
to  the  MTBP/MTBMA,  which  will  increase  if 
improved.  If  applied  to  the  failure  rate, 
the  PV  would  have  a  negative  value;  an 
improved  rate  would  be  lover.  Magnitude 
would  be  adjusted  accordingly. 


Substep  Group  1D _ 

Reliability  and  Maintainability  Analysis 


Overview 


Results  of  this  substep  group  include  the 
quantitative  reliability  and  maintainability 
(RfcM)  parameters  associated  with  the 
Predecessor,  BCS,  and  Proposed  System 
alternatives.  R&M  parameter  values  for  all 
alternatives  are  provided  to  the  maintainer 
workload  calculations. 

Reliability  is  defined  by  Army  Regulation 
702-3  (Reliability  and  Maintainability),  as 
"the  probability  that  an  item  will  perform 
its  intended  function  for  a  specified 
interval  under  stated  conditions.”  When  a 
reliability  parameter  is  being  determined, 
the  practical  applications  of  this  definition 
are  limited. 

AMC/TRADOC  Pam  70-11  (RAM  Rationale  Report 
Handbook)  recognizes  at  least  two  other,  more 
inclusive  definitions.  HARDMAN  reliability 
analysis  uses  the  broadest  definition,  where 
the  reliability  parameter  is  considered  as 
the  demand  for  maintenance  resources.  This 
concept  is  also  termed  "operating  and  support 
cost  reliability.” 

AR  702-3  defines  maintainability  as  ”a 

characteristic  of  design  and  installation 

which  provides  inherently  for  the  item  to  be 

retained  in  or  restored  to  a  specified 

condition  within  a  given  time,  when  the 

maintenance  is  performed  in  accordance  with 

prescribed  procedures  and  practices.”  A 

HARDMAN  application  includes  efforts  to 

estimate  all  of  the  maintenance  requirements 

associated  with  a  given  design,  not  only 

those  inherent,  or  fundamental,  to  the  design 

itself. 

% 

Aspects  of  the  system's  operational  and 
maintenance  environment  also  induce  the 
requirement  for  maintenance  to  be  performed. 
The  HARDMAN  methodology  endeavors  to  capture 
the  parameter  values  associated  with  this 
situation.  Drawing  a  distinction  between 
inherent  and  induced  maintenance  allows  the 


analyst  to  estimate  the  probable  success  of 
design  solutions  to  lover  manpower, 
personnel,  and  training  (MPT)  requirements 
based  on  R&M  parameters.  This  capability  is 
particularly  valuable  in  Substep  6,1 
(Identify  Tradeoff  Alternatives). 


The  Predecessor,  BCS,  and  Proposed  System 
alternatives  were  defined  in  Substep  Group  1C 
(Equipment  Comparability  Analysis).  Also, 
design  differences  and  their  impacts  were 
identified  for  BCS  and  Proposed  System 
alternatives. 

In  Substep  1.9,  reliability  and 
maintainability  parameters  are  identified  and 
assigned  to  each  system  alternative.  These 
parameters  are  used  to  derive  maintainer 
workload  in  Substep  2.5  (Determine  Maintainer 
Workload) . 

Historical  and  projected  RfcM  data  are 
collected,  analyzed,  and  adjusted  to  insure 
consistency  across  alternatives.  If 
necessary,  the  perturbation  values  (PVs) 
developed  in  Substep  1.8  (Determine  Design 
Differences)  are  applied  to  the  BCS  R(;m 
parameter  values  to  estimate  values  for  the 
Proposed  System  alternatives.  RLM  parameter 
values  for  all  alternatives  are  provided  to 
the  maintainer  workload  calculations  in 
Substep  2.5  (Determine  Maintainer  Workload). 

Figure  lD-1  depicts  the  logic  flow 
determining  the  RfcM  parameter  requirements  of 
the  system  alternatives.  This  figure  shows 
the  major  input,  processes,  and  output  of  the 
substep  group.  As  shown  in  the  figure,  this 
substep  group  consists  of  Substep  1.9 
(Determine  Reliability  and  Maintainability 
Requirements),  which  contains  four  action 
ps 


Substep  1 .9/Overview 

Determine  Reliability  and  Maintainability  Requirements 


Objective 


Input 


Products 


Logic 


The  objective  of  this  substep  is  to 
develop  values  for  reliability  and 
maintainability  (R&M)  parameters  for  the 
Predecessor,  BCS,  and  Proposed  System 
alternatives. 


Input  from  other  HARDMAN  substeps 
includes  the  Predecessor,  BCS,  and  Proposed 
System  equipment  structures  and  their 
descriptive  information  from  Substeps  1,5, 
1.6,  and  1.7,  respectively.  The  Design 
Difference  Index  (DDI)  for  each  BCS/Proposed 
System  comparison  is  obtained  from  Substep 
1.8. 

Other  input  includes  historical  and  projected 
R&M  data  on  each  alternative.  This 
information  may  be  obtained  from  maintenance 
data  collection  programs  of  the  military 
services;  development,  operational,  and/or 
independent  test  results;  engineering 
estimates  from  government  or  private 
subject-matter  experts;  and  relevant  reports 
and  documentation. 


The  products  of  this  substep  are 
quantitative  R6M  parameters  for  each  system 
alternative.  These  values  are  used  to 
determine  maintainer  workload  in  Substep  2.5 
(Determine  Maintainer  Workload). 


Figure  lD-1  depicts  the  logic  flow  for 
determining  R&M  par imeter  requirements.  As 
shown  in  the  figure,  this  substep  entails 
four  action  steps.  The  first  two  action 
steps  are  performed  simultaneously,  then 
followed  by  Action  Step  3.  Action  Step  4  is 
applied  only  when  RfiiM  values  for  the  Proposed 
System  must  be  estimated  with  the 
perturbation  values  (PVs)  developed  in 
Substep  1.6. 
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Action  Steps 
Action  Step  1: 

Requirements 


Objective 

Procedures 


Determine  Reliability  and  Maintainability  [R&M]  Parameters 

Selection  of  suitable  R&M  parameters  is 
directly  related  to  the  determination  of 
maintainer  workload  and  manpower  in  Step  2 
(Manpower  Requirements  Analysis),  Several 
different  parameters  may  express  the  same 
information,  or  several  may  be  combined  in 
different  ways  to  obtain  the  same  result. 
Different  sources  of  R&M  data  use  different 
parameters.  Note  that  different  parameters 
may  be  appropriate  for  dissimilar  systems. 

When  evaluating  the  usefulness  of  the  data 
sources,  the  analyst  must  know  the  parameters 
of  interest  to  susbsequent  HARDMAN  steps.  If 
the  parameters  are  not  to  be  obtained 
directly  from  the  data  source,  the  analyst 
must  determine  whether  the  parameters  can  be 
derived  from  available  data. 


The  objective  of  this  action  step  is  to 
determine  what  R&M  parameters  are  most 
suitable  for  application  in  Substep  2,5 
(Determine  Maintainer  Workload), 

1,  The  analyst  consults  with  the  Workload 
analyst  and  determines  the  parameters  or  data 
elements  needed  to  support  determination  of 
maintainer  workload.  These  data  elements  are 
contained  in  Substep  2,5  (Determine 
Maintainer  Workload)  but  repeated  in  Table 
1.9-1  for  convenience. 


Table  1,9-1,  Maintenrnce  Workload  Data  Elements 
Workload  Equation  Data  Elements 


Use  Quantitative  requirements  for 

operational  system  activity/use 
under  scenario  conditions; 
expressed  in  all  relevant 
metrics  (miles  driven,  rounds 
fired,  hours  (  'erated,  etc.) 
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Table  1.9-1 

Maintenance  Workload  Data  Elements  [coni] 

Workload  Equation  Data  Elements 

Period 

Duration  of  the  scenario  re¬ 
quirement  (day,  week,  month, 
year) 

Actions 

Number  of  maintenance  actions  for 
each  action  type  (remove,  replace, 
repair,  troubleshoot) 

Labor 

Maintenance  man-hours  (MMH)  for 
one  action  of  each  type 

Other  Descriptive  Information 

For  Actions 

Cause 

Primary  reason  for  the  action 
(hardware,  software,  operator 
error,  maintenance  error,  accident) 

Effect 

The  result  or  outcome  of  the  action 
on  the  system's  mission 

For  Labor 

MOSC, 
Paygrade, 
and  Duty 
Position 

For  the  maintainer  who  is  assigned 
responsibility  and/or  is  performing 
the  action 

Mainte¬ 

nance 

Level 

Where  the  action  occurs 

Mean  Time 
to  Repair 

Average  elapsed  time  required 
to  perform  the  action 

(MTTR) 

Number  of 

Hain- 

tainers 

If  the  action  requires  more  than 
one  maintainer  in  order  to  be 
performed  successfully 

10-7 
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Such  detailed  descriptions  of  the  data 
elements  may  not  exist.  Instead,  they  may  be 
expressed  simply  as  a  "maintenance  ratio" 
(MR).  A  maintenance  ratio  is  defined  as  the 
ratio  of  maintenance  man-hours  to  a  unit  of 
system  usage.  Examples  include  14 
maintenance  man-hours  per  flying  hour,  2.5 
maintenance  man-hours  per  mile,  etc. 

Typically,  an  MR  is  expressed  just  for  all 
maintenance  workload  at  a  particular 
maintenance  level  or  echelon.  However,  in 
theory  an  MR  is  the  product  of  the 
reliability  and  maintainability  terms  of  the 
maintenance  workload  equation.  Consequently, 
it  can  be  computed  for  one  or  all  maintenance 
tasks  or  actions  associated  with  one  EIC. 

For  the  R&M  analyst,  the  equation  usually 
takes  the  following  form: 


Reliability  x  Maintainability  *  MR 

1  Manhours 

X  MTTR  X  K  «  - 

One  Metric 


Mean  [Metric]  Between  the 
Maintenance  Action  being 
analyzed,  with  the  metric 
expressed  in  time  (MTBMA), 
rounds  (MRBMA),  etc. 

Mean  Time  To  Repair,  or  the 
average  elapsed  or  clock  time 
required  to  complete  the  action 

Number  of  people  required  for  the 
action,  a  factor  needed  in  order 
to  convert  clock  time  to  man-hours 

M[M]BMA,  MTTR,  K,  and  MR  thus  become  the  RtM 
parameters  of  practical  concern  to  the  R&M 
analyst.  MR  by  itself  may  be  a  more  summary 
parameter  than  those  used  to  derive  it.  The 
analyst  should  select  the  parameters  at  a 


MIMJBMA 
Where: 
M[M]BMA  > 

MTTR 

K 


level  of  detail  which  meshes  with  the 
available  data  and  the  scope  of  the  analysis. 

2.  Values  for  the  R&M  parameters  may  not  be 
available  on  a  task-by-task  or  an 
action-by-action  basis.  However,  they  may  be 
available  for  more  summary  groupings,  or 
"workload  categories."  Maintenance  workload 
is  categorized  as  either  Preventive  or 
Corrective  Maintenance.  These  categories  are 
defined  as  follows: 


•  Preventive  Maintenance  (PM).  Maintenance 

actions  are  conducted  at  scheduled, 
periodic  intervals  on  operational  systems, 
equipment,  or  components.  These  actions 
contribute  to  uninterrupted  operation 
within  design  characteristics.  Some 
examples  are:  check  fluids  prior  to 
operating,  clean  and  lubricate  daily,  and 
rotate  annually. 

•  Corrective  Maintenance  (CM).  This  category 
covers  maintenance  performed  on  an 
unscheduled  basis  due  to  malfunction, 
failure,  deterioration,  or  battle  damage. 
These  maintenance  actions  are  required  to 
restore  disabled  systems,  equipment,  or 
components  to  an  operational  condition 
within  predetermined  tolerances  and 
limitations.  Corrective  Maintenance 
includes  such  activities  as:  repair 
broken  pipe,  replace  burned  transformer, 
and  patch  ripped  canvas  cover. 


3.  Some  sources  of  RfcM  data  distinguish 
between  "inherent”  and  "induced"  maintenance. 
This  distinction  reflects  the  cause  or  reason 
for  a  particular  maintenance  action  (see 
Cause  in  Table  1.9-1).  Sometimes  cause  is 
referred  to  as  "chargeability, "  i.e.,  the 
aspect  of  the  system  or  its  environment  to 
which  the  action  may  be  charged. 
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Inherent  maintenance  actions  result  from 
characteristics  of  the  system  itself  — 
problems  with  its  design,  hardware,  software, 
or  manufacturing  quality  control. 

Induced  maintenance  actions  result  from  the 
system’s  operating  environment  — 
shortcomings  in  the  skills  of  its  operators 
and  maintainers,  the  availability  of  spare 
parts,  the  readability  of  system  technical 
documentation,  etc. 

Table  1.9-2  cross-references  the  chargeable 
elements  described  in  TRADOC/AMC  Pamphlet 
70-11  (Reliability,  Availability,  and 
Maintainability  Rationale  Report  Handbook) 
with  the  more  summary  descriptions  typically 
found  in  the  data  sources  and  employed  in 
HARDMAN. 

The  analyst  develops  factors  from  the 
available  data  which  permit  the  inherent  vs. 
induced  distinction  to  be  made  for  the 
M[M]BMA  metric.  This  distinction  enables  the 
analyst  to  estimate  whether  (1)  design 
solutions  to  improve  inherent  RtM  parameters 
will  be  successful  or  (2)  effort  would  be 
better  spent  on  reducing  induced  maintenance. 


Action  Step  2:  Evaluate  R&M  Data  Sources 


Rtquirtmtnts  The  R&M  data  sources  incorporated  depend  on 

the  various  equipment  and  system 
configurations  defined  in  Substep  Group  1C 
(Equipment  Comparability  Analysis).  These 
data  sources  are  established  by  the  type  of 
system  being  analyzed,  e.g..  Predecessor, 
BCS,  or  Proposed.  The  analyst  identifies 
candidate  R&M  data  sources,  evaluates  them, 
and  selects  the  most  appropriate  ones  to 
support  development  of  the  required  R&M 
parameter  values. 
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Table  1.9-2.  Causes  of  Maintenance  Action 

TRADOC/AMC  Pamphlet  70-11 

HARDMAN 

Categories 

Chargeable 

Elements 

Includes 

Inherent 

Hardware 

Hardware  and  personnel-related’ 
incidents  attributable  to 
hardware  design 

Software 

Embedded  computer  software, 
including  BITE  software,  and 
personnel-related  incidents 
attributable  to  software 
characteristics 

Induced 

\ 

Crew 

(Self-explantory) 

Maintenance 

Personnel 

(Self-explanatory) 

Manuals 

Personnel-related  incidents 
attributable  to  misleading, 
incorrect,  or  missing 
information 

Support 

Equipment 

Special  and  common  tools, 
spares,  repair  parts,  and 
associated  support  equipment 
and  software 

other 

Accident 

Only  accidents  which  cannot 
be  charged  to  one  of  the 
other  elements 

• 

ID-ll 
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Objective 


Procedures 


The  objective  of  this  action  step  is  to 
select  R&M  data  sources  which  best  support 
development  of  the  required  R&M  parameter 
values. 

The  analyst  must  evaluate  each  potential  data 
source  to  determine  if  its  data  will- support 
development  of  R&M  parameter  values  for  one 
or  more  system  alternatives.  Table  1.9-3 
depicts  typical  data  sources,  the  type  of  R&M 
data  elements  generally  available  from  each 
source,  and  the  general  applicability  of  the 
data  source  to  each  HARDMAN  system 
alternative. 

After  a  thorough  evaluation  of  available 
technical  data,  the  analyst  selects  one  or 
more  sources.  The  following  decision-making 
criteria  are  used  to  select  data  sources: 


•  Predecessor  —  R&M  data  for  the 
Predecessor  System  are  required  if  the 
manpower  requirements  of  the  Predecessor 
System  are  to  be  calculated  rather  than 
determined  by  allocation  of  existing 
requirements.  The  analyst  should  consult 
with  the  Manpower  analyst  to  determine  the 
more  appropriate  method. 

If  RCiM  data  is  required,  field  data  should 
be  available.  If  not,  MARC  provides 
estimated  maintenance  man-hour  (MMH) 
requirements  for  each  MOS  associated  with 
Predecessor  Systems. 

Note  that  field  data  and  MARC  estimate:; 
may  be  inconsistent.  This  situation 
should  be  less  likely  in  the  future,  as 
field  data  from  Sample  Data  Collection 
(SDC)  are  gradually  replacing  the 
engineering  estimates  which  comprise  most 
of  the  current  MARC. 

•  Baseline  Comparison  System  (BCS)  — 
Selected  data  must  satisfy  the  data 
criterion  for  inclusion  in  the  BCS.  In 
other  words,  data  must  be  based  on 
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Examples 
Example  1 


Example  2 


observations  under  field  conditions.  The 
best  source  of  data  is  the  one  with  the 
most  observations  (see  Substep  1.6, 
Establish  BCS). 

e  Proposed  System  —  If  actual  data  on  the 
Proposed  System  are  to  be  used,  the  data 
can  come  from  other,  non-field  sources  and 
can  have  a  limited  number  of  observations. 
System  components  which  satisfy  all 
criteria  except  BCS  data  but  have  some 
data  available  are  good  sources  of 
Proposed  System  R&M  data. 


Situation.  An  ongoing  sample  data  collection 
(SDC)  has  fielded  R&M  data  for  the  last  three 
years  on  the  Predecessor  System.  The  data 
are  available  from  the  AMC  system  proponent. 

Result.  The  analyst  obtains  the  SDC 
information  for  at  least  two  years  and  uses 
the  data  to  establish  Predecessor  System  RtM 
values.  To  the  extent  that  Predecessor 
components  are  included  in  the  BCS,  the 
values  obtained  also  satisfy  the  BCS 
criteria. 


Situation.  Three  Army  SDCs,  a  DT/OT  test 
report,  and  information  from  the  Navy’s 
maintenance  data  collection  system  (3M)  are 
available  to  support  the  selection  and  use  of 
candidate  BCS  subsystems  and  components. 

Result.  The  analyst  orders  all  relevant  R&M 
documentation  from  the  Army  and  the  Navy. 

This  information  is  evaluated  for  use  as  R&M 
parameters  for  the  BCS.  The  most  appropriate 
R6M  data  sources  for  the  BCS  are  selected. 
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Examplf  3 


Action  Step  3: 

RtquIrtmtnU 


Ob|tctlvt 


Proctduras 


Situation.  Subject-matter  experts  (SMEs)  are 
available  in  various  Army  R&D  programs  and 
technology  labs  for  most  of  the  new 
technology  being  incorporated  into  the 
Proposed  System.  Also,  LSAR  and  a  draft  set 
of  technical  manuals  have  been  developed  for 
one  Proposed  System  alternative. 

Decision.  The  analyst  consults  with  the  SMEs 
to  develop  perturbation  values  (PVs)  (see 
Substep  1.6,  Determine  Design  Differences). 
LSAR  input  records  and  specific  LSAR  output 
summary  reports  are  ordered.  In  addition, 
selected  TMs,  e.g.,  operator  rind  maintenance 
types,  are  procured  for  posci^iie  use  in 
determining  preventive  maintenance 
requirements  for  the  Proposed  System 
alternative. 


Normalize  Data  as  Applicable 


The  analyst  must  adjust  the  values  obtained 
for  the  R&M  parameters  to  insure  consistent 
units  of  measure  across  data  sources. 


The  objective  of  this  action  step  is  to 
insure  that  all  R&M  parameter  values  are 
consistent  and  include  all  required  elements. 


This  action  step  has  no  specific  procedures. 
In  short,  the  analyst  must  insure  that  the 
RSK  parameter  values  obtained  from  all 
sources  are  in  the  correct  dimensions  and 
contain  all  required  elements. 
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Examples 
Example  1 


Example  2 


From  Sample  Data  Collection  for  one  year,  the 
engine  group  for  one  helicopter  required  8.0 
corrective  maintenance  man-hours  (CM  MMH)  and 
15.00  preventive  maintenance  man-hours  (PM 
MMH)  for  a  group  total  of  23.0  MMH  at  the 
organizational  level  of  maintenance. '  During 
this  period,  the  helicopter  model  operated  an 
average  of  103.2  flight  hours  (FH)  per 
aircraft.  The  engine  group  maintenance  ratio 
per  aircraft  is  calculated  as  follows: 


MR 

ORG 


23.0  MMH 
103.2  FH 
.22 


The  above  calculation  shows  that  this 
engine  group  requires  .22  man-hours  per 
operational  hour  at  the  organizational 
maintenance  level.  Similar  values  would 
be  calculated  for  the  other  maintenance 
levels  being  evaluated. 


Another  approach  to  determine  a  corrective 
maintenance  ratio  is  to  apply  the  metrics  of 
the  total  number  of  maintenance  actions  (MAs) 
and  the  total  maintenance  man-hours  per 
maintenance  action  (MMH/MA)  with  the  average 
flight  hours  per  aircraft  in  a  given  period 
of  time.  A  different  helicopter  model  has 
the  following  field  data  available  for  its 
engine  group: 


Annual  FHs  »  103.2  FH 

Annual  MAs  *  0.2  actions 

MMH/MA  «  2.4 
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The  field  data  do  not  include  preventive 
maintenance  data.  Preventive  maintenance 
requirements  are  obtained  from  system 
technical  manuals  (TMs).  Helicopter  TMs 
indicate  that  263.0  PM  MMH  are  required  to 
support  the  engine  annually.  The  maintenance 
ratios  are  calculated  as  follows: 


MR  -  8.2  MAS  X  2.4  MMH/MA 

ORGfCM)  - 

^  103.2  FH 

«  .19  MMH/FH 


MR  ,  -  263.0  MMH/Year 

org(pm) - 

103.2  FH/Year 

-  2.55  MMH/FH 


Therefore,  the  total  MR  at  the  organizational 
level  is: 


MR  «  .19  ♦  2.55 

ORG 


2.74  MMH/FH 
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Example  3 


A  final  approach  is  to  determine  a  corrective 
maintenance  ratio  when  only  an  inherent  value 
is  available  from  the  primary  data  source. 

The  situation  described  below  illustrates 
this  approach. 

The  Proposed  System  is  a  remotely  piloted 
vehicle  (RPV).  The  materiel  contractor  has 
furnished  a  Logistic  Support  Analysis  Record 
(LSAR)  which  yields  an  inherent 
(design-related)  corrective  maintenance  ratio 
of  0.34  MMH/FH  at  the  organizational  level. 
Review  of  a  fielded  corrective  MR  for  this 
system  is  0.85.  This  system’s  original 
inherent  LSAR  MR  was  projected  to  be  0.55. 

The  induced  corrective  MR  is  computed  as: 


Induced  MR 
Org  (cm) 


Fielded  MR  -  LSAR  MR 

CM  CM 

0.85  -  0.55 

0.30  MMH/FH 


The  percentage  of  the  induced  MR  versus  the 
total  MR  is  calculated  as  follows; 


%  MR 

Org 

Ind  CM 


Induced  MR 

CM 


Fielded  MR 

CM 

0.30 

0.85 


0.35 
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Therefore,  using  the  calculated,  historical 
MR  percentages  for  a  comparable  system,  the 
total  RPV  corrective  MR  equals: 


MR 


Org(^ 


Inherent  MR  x 


CM  1  -  %  Induced  MR 


CM 


0.34 

X 

1  -  0.35 

0.34 

X 

1 

0.65 

0.34 

X 

1.54 

0.52 

MMH/FH 

Action  Step  4:  Apply  Perturbation  Values  ’ 


Rtquirtmtnts  An  index  of  design  differences  was 

established  in  Substep  1.8  (Determine  Design 
Differences).  This  substep  identified  new 
technologies  or  actual  components  that  could 
be  incorporated  into  the  proposed  designs. 

Additionally,  this  step  developed 
perturbation  values  (PVs)  reflecting  the 
introduction  of  the  new  technology.  The  PVs 
are  used  to  estimate  parameter  values  for  the 
Proposed  System  when  data  on'  Proposed  System 
components  are  not  available.  The  analyst 
must  apply  the  PVs  to  the  BCS  values  in  order 
to  obtain  the  Proposed  System  values. 
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Objective 


Procedures 


Example 


The  purpose  of  this  action  step  is  to  apply 
perturbation  values  (PVs)  to  BCS  parameters 
in  order  to  obtain  values  for  the  Proposed 
System. 


The  analyst  obtains  the  PV  for  an  EIC  from 
the  Design  Difference  Index  (DDI).  The 
analyst  reviews  the  design  differences  and 
confirms  the  potential  impact  of  the  PV  on 
BCS  R&M  data.  The  PV  is  then  applied  to  the 
appropriate  R&M  data  element  to  produce  the 
adjusted  R&M  data. 


Proposed 

System 

Parameter 

Value 


BCS 

Parameter  x  (1  +  PV) 
Value 


This  relationship  is  accurate,  provided  the 
PV  is  expressed  as  a  decimal  with  a  plus  or 
minus  sign  as  appropriate. 

Situation.  An  improved  engine  in  the 
Proposed  System  is  estimated  to  improve  the 
MTTR  of  the  BCS  engine  by  ten  percent.  The 
BCS  MTTR  is  1.9  hours. 

Results.  The  PV,  -.10,  is  applied  to  the 
MTTR.  ("Improving"  the  MTTR  means  reducing 
it.)  The  analyst  obtains  the  following 
result ; 

Proposed 

System  =  1.9  x  (1  +  (-.10)) 

MTTR 

=  1.9  X  .90 


1.71  hours. 


Substep  Group  1E 
Tcsk  Identification 


Overview 


Task  identification  is  the  next  logical  step 
beyond  the  functional  identification  and 
allocation  process  described  in  Substep  1.3 
(Determine  Functional  Requirements).  During 
this  phase,  the  functions  allocated  to 
people,  either  alone  or  in  combination  with 
equipment  and  software,  are  further  analyzed 
to  identify  tasks. 

As  used  in  this  analytic  process,  the  term 
"task”  means  human  performance  of  some  sort. 
Tasks  may  be  characterized  as  equipment-  or 
non-equipment-based. 

Task  identification  results  in  specification 
of  what  tasks  operators  and  maintainers  of 
the  BCS  and  Proposed  System(s)  will  perform. 

>  single  task  identification  step,  rather 
than  a  series  of  isolated  actions,  is 
preferable.  The  single  step  avoids  the 
redundant,  time-consuming  aspects  of  task 
identification  independently  developed  by 
trainers  and  manpower  analysts. 

The  single  step  also  avoids  the  problem  of 
integrating  and  organizing  data  independently 
developed.  Hence,  without  a  common  point  of 
departure  for  subsequent  task  analysis,  it 
becomes  difficult  to  relate  the  impact  of 
mission,  functional  requirements,  and 
equipment  on  manpower,  personnel,  and 
training  requirements. 

The  desired  outputs  of  task  identification 
are  generic  task  taxonomies  for  each  of  the 
BCS  and  Proposed  Systems.  These  task 
taxonomies  are  at  a  high  level  of 
abstraction. 

Ideally,  this  level  is  the  minimum  necessary 
to  support  delineation  of  the 
interrelationships  among  system  missions, 
system/subsystem  functions,  and  specific 


equipment  selected  for  the  BCS  and  Proposed 
Systems.  This  level  is  also  the  minimum 
needed  to  outline  associated  tasks  and  also 
to  exclude  certain  tasks  based  on  the 
selection  of  specific  equipment,  which 
distinguished  the  task  taxonomies  developed 
in  this  phase. 


The  logic  flow  for  task  identification  is 
presented  in  Figure  lE-1.  Substep  1.10 
(Determine  Generic  Tasks)  is  the  only  substep 
required.  In  this  substep,  separate 
procedures  are  described  for  identifying  both 
generic  operator  tasks  and  maintainer  tasks. 
Two  separate  procedures  are  required  because 
maintenance  tasks  are  a  function  of  equipment 
design,  while  operation  tasks  depend  on  both 
equipment  design  and  operational  doctrine. 
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Determine  Generic  Tasks 


Objective 


Input 


The  purpose  of  this  step  is  to  establish  a 
generic  set  of  tasks  which  will  be  performed 
by  the  operators  and  maintainers  of  the 
system  under  analysis.  These  tasks  are 
termed  "generic**  because  they  should  provide 
a  common  basis  of  understanding  and  an 
analytic  departure  point  for  subsequent 
manpower  and  training  analyses. 

The  term  "task"  typically  has  different 
meanings  to  manpower  and  training  analysts. 
Consequently,  the  language  used  to  describe 
the  generic  tasks  must  be  abstract  enough  so 
that  both  manpower  and  training  analysts  can 
relate  to  them.  Determining  generic  tasks  in 
this  manner  establishes  the  audit  trail  from 
both  manpower  and  training  analyses  back  to 
equipment,  functional,  and  mission 
requirements  of  the  system. 


Input  from  other  HARDMAN  substeps  includes 
the  detailed  mission  requirements  from 
Substep  1.2,  functional  requirements  from 
Substep  1.3,  BCS  and  Proposed  System 
equipment  lists  from  Substeps  1.6  and  1.7, 
and  the  Design  Difference  Index  developed  in 
Substep  1.8. 

The  Design  Difference  Index  indicates  the 
variances  between  the  BCS  and  Proposed 
Systems  from  Substep  1.8.  Input  from  various 
sources  includes  technical  manuals  and  other 
descriptions  of  the  operation  and  maintenance 
requirements  of  equipment.  Also  consulted 
are  field  manuals  and  other  doctrinal  sources 
that  describe  human  tasks  not  related  to 
equipment. 


# 
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Product  The  product  of  this  substep  is  a  set  of 

generic  tasks  for  the  system  under  analysis 
which  will  apply  to  both  the  BCS  and  Proposed 
Systems. 


Logic  In  HARDMAN,  the  term  "task"  refers  to 

necessary  system  operations  and  maintenance 
activities  which  require  human  performance. 
Tasks  exist  in  the  middle  of  a  continuum  of 
analysis  levels  (see  Table  1.10-1).  Thus, 
tasks  are  the  link  between  higher-level 
analyses  of  the  system  as  a  whole  and 
lower-level  analyses,  such  as  those  of 
training  tasks. 

Because  manpower  and  training  analyses  view 
human  performance  from  different 
perspectives,  development  of  a  common  set  or 
taxonomy  of  tasks  is  necessary. 

The  manpower  analyst  regards  tasks  primarily 
as  a  bookkeeping  device  for  apportioning  or 
accounting  for  system  workload.  The  training 
analyst,  on  the  other  hand,  views  tasks  as 
the  basic  objective  of  training. 

It  is  at  the  task  level  that  decisions  are 
made  about  whether  training  is  needed  and,  if 
training  is  needed,  in  what  setting  it  is 
best  conducted.  Tasks,  therefore,  become  the 
focus  of  training  resource  allocation  and  are 
the  beginning  point  of  the  training 
development  process. 

Manpower  analysis  uses  tasks  that  are  located 
at  the  bottom  of  the  hierarchy  of  system  and 
subsystem  missions  and  functions.  Training 
analysis  uses  tasks  placed  above  the 
behaviors  captured  by  subtasks  and  task 
elements. 

For  example,  the  manpower  analyst  can  assign 
workload  to  a  task  described  as  "Aim  Cannon." 
The  training  analyst  goes  beyond  this  level 
to  the  cognitive  and  psychomotor  behaviors 
required  for  successful  task  performance. 
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Thus,  the  requirement  for  a  task  description 
generic  enough  to  suit  both  manpower  and 
training  analyses  is  satisfied  by  the  higher 
level  of  abstraction  associated  with  manpower 
tasks. 

Figure  lE-1  represents  the  logic  flow  for 
determining  generic  tasks.  Action  Step  1 
yields  a  description  of  operator  tasks,  while 
Action  Step  2  results  in  a  description  of 
maintainer  tasks. 


Table  t.tO-t.  Analysis  Levels 


Level/Object 
of  Analysis 

Purpose  of  Analysis 

Example 

System 

To  determine  effectiveness 
of  the  system  in  performing 
a  specified  mission 

Self-pro¬ 

pelled 

howitzer 

Subsystem 

To  determine  the  best  way 
to  meet  a  specified  re¬ 
quirement  of  the  mission 

Cannon 

Function 

To  determine  the  best  com¬ 
bination  of  components  re¬ 
quired  to  make  up  the  sys¬ 
tem 

• 

Shoot 

Task 

To  determine  the  best  al¬ 
location  of  human  capa¬ 
bilities  in  order  to  per¬ 
form  required  functions 

Load  and 

Fire  a 

Prepared 

Round 

Sub-task 

To  determine  the  best 

use  of  human  capabilities 
for  accomplishing  the 
assigned  task 

Fire 

Cannon 

Element 

To  determine  the  best 

use  of  human  capabilities 
in  order  to  perform 
assigned  sub-tasks 

Attach 

Lanyard 

IE- 7 
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Action  Steps 

Action  Step  1: 

Requirements 


Objective 


Procedures 


Describe  Operator  Tasks 

In  this  action  step,  the  analyst  describes 
operator  tasks  using  information  system 
functional  requirements  and  mission  analyses. 


The  purpose  of  this  action  step  is  to 
establish  a  comprehensive  operator  task  list 
for  the  BCS  and  the  Proposed  Systems. 


Tasks  required  for  operation  of  both  the  BCS 
and  the  Proposed  System  are  a  function  of 
each  system  alternative’s  specific  equipment 
as  veil  as  its  doctrinal  requirements. 
Development  of  operator  tasks  for  equipment 
is  based  on  their  operating  characteristics. 
Operator  tasks  can  be  derived  by  inspecting 
relevant  operator’s  manuals. 

Other  non-equipment-related  operator  tasks, 
especially  those  required  for  the  functions 
of  command  and  control  and  communicate,  are 
more  difficult  to  determine.  Identification 
of  these  tasks  requires  greater  analytical 
judgment  and  reliance  on  comparable  weapon 
systems. 

Typically,  documentation  on  similar  weapon 
systems  within  the  same  functional  branch 
provides  the  greatest  source  of  operator  task 
information.  Table  1.10-2  presents  a  sample 
list  of  operator  action  words  that  may  be 
useful  in  developing  operator  tasks. 
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Table  1.10-2.  Sample  Operator  Action  Words 


Activate 

Detect 

Listen  for 

Press 

Stow 

Adjust 

Diagnose 

Load 

Pull 

Synthesize 

Aim 

Direct 

Locate 

Push 

Tighten 

Allocate 

Distinguish 

Loosen 

Raise 

Trace 

Arrange 

Draft 

Lubricate 

Recognize 

Track 

Assemble/Dis- 

Drive 

Maneuver 

Regulate 

Transcribe 

Assign 

Energize/De- 

March 

Remove 

Translate 

Calculate 

Evaluate 

Mate 

Replace 

Troubleshoot 

Categorize 

Fire 

Match 

Respond 

Tune 

Check 

Fly 

Mix 

Rotate 

Turn  on/off 

Classify 

Grasp 

Monitor 

Run 

Twist 

Clean 

Group 

Navigate 

Schedule 

Wait 

Close/Open 

Guide 

Observe 

Select 

Watch 

Collect 

Identify 

Operate 

Service 

Weld 

Compute 

Inspect 

Order 

Set  up 

Write 

Connect/Dis- 

Install 

Pick 

Sharpen 

Construct 

Isolate 

Pick  up 

Slide 

Control 

Itemize 

Pilot 

Sort 

Coordinate 

Lead 

Plan 

Specify 

Copy 

Lift 

Prepare 

Stencil 

Action  Step  2:  Describe  Maintainer  Tasks 

Rtquirtmtnt  In  this  action  step,  the  analyst 

describes  maintainer  tasks  using  a 
generic  set  of  maintenance  action  words 
and  a  generic  equipment  structure. 


Ob|eetlvt  The  purpose  of  Action  Step  2  is  to 

establish  a  comprehensive  maintainer 
task  list  for  the  BCS  and  the  Proposed 
Systems. 


Procedures  Maintenance  tasks  required  for  both  the 

BCS  and  the  Proposed  System  are  a 
function  of  the  specific  equipment  and 
components  selected  for  inclusion  in  the 
respective  system  concepts.  The 
potential  list  of  maintenance  tasks  is 
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the  product  of  the  number  of  unique 
items  on  the  system  equipment  list 
(level  of  indenture,  equipment  breakdown 
structure)  and  the  standard  set  of 
maintenance  action  verbs.  (Several 
"standard"  lists  are  available;  see 
Table  1.10-3.) 

The  specific  set  of  maintenance  tasks 
required  for  a  particular  system  concept 
is  derived  by  deleting  potential  tasks 
which  do  not  apply.  They  may  not  apply 
either  because  none  is  required,  a 
particular  task  is  not  within  the 
study's  scope,  or  for  other  reasons. 

The  remaining  tasks  are  required  for  the 
BCS  and  Proposed  System  and  are 
expressed  in  verb-object  form  (e.g., 
"Repair  Engine,"  "Replace  Radio,"  etc.). 
The  level  of  detail  at  which  a  task  is 
stated  depends  strictly  on  the  level  of 
indenture  (and  hence  detail)  in  the 
generic  and  Proposed  System  equipment 
structures) . 


Table  1.10-3.  Sample  Maintenance  Action  Words 


Sample  Data 
Collection 


Replace 
Repa i r 
Preventive 
Adjust 
Other 


AMC 

Pam  750-16 


Inspect 
Test 
Service 
Adjust 
Al  ign 
Calibrate 
Install 
Remove  and 
Replace 
Repair 
Overhaul 
Rebui Id 


Maintenance 


Inspect 
Test 
Service 
Purge 
Adjust 
Remove  and 
Install 
Replace 
Repair 
Overhaul 
Rebui Id 


Glossary 


Action  Rate  The  preventive  maintenance  action  rate  measured 
as  the  number  of  occurrences  (i.e.,  demand)  per  life  unit 
(calendar/clock  time,  miles/kilometers  traveled,  rounds 
fired  or  number  of  activations);  (paraphrased  from  AR 
570-2). 

Additional  Skill  Identifier  (ASI )  A  code  added  to  the 
specialty/MOS  to  designate  greater  specialization  (AR 
351-1).  For  example,  soldiers  with  either  IIB,  12B,  19D  MOS 
who  receive  Dragon  Gunnery  Training  are  assigned  the  ASI  C2. 

Administrative  Time  POI  time  allotted  for  administrative 
functions  as  opposed  to  course/training  related  functions. 

Advanced  Individual  Training  (AIT)  Skill  training  given 
enlisted  personnel  after  completion  of  basic  training,  so  as 
to  qualify  them  for  the  award  of  an  MOS  and  to  perform  the 
basics  of  their  job  upon  initial  assignment  to  a  unit  (AR 
351-1). 

Noncommissioned  Officer  Course  (AHCOC)  A  course  that 
stresses  MOS-related  tasks  with  emphasis  on  technical  and 
advanced  leadership  skills,  and  knowledge  of  military 
subjects  required  to  train  and  teach  other  soldiers  at  the 
platoon  and  comparable  level  (AR  351-1). 

Annex  Logical  divisions  in  a  program  of  instruction  (POI) 
that  cluster  tasks  into  blocks  of  instruction.  Within  each 
annex  are  lessons  (identified  by  file  numbers)  which  are 
designed  to  instruct  the  tasks. 

Annual  Accessions  The  number  of  individuals  who  must  be 
recruited  in  a  year. 

Annual  Costs  Total  cost  of  training  computed  on  an  annual 
basis. 

Annual  Course  Costs  Total  course  cost  and  individual  course 
cost  elements  computed  on  an  annual  basis. 

Annual  Course  Resources  Products  of  Training  Cost  and 
Resources.  Include  number  of  instructors  required,  training 
cost,  and  training  man-days. 

Annual  Instructor  Requirements  The  number  of  instructors 
required  to  deliver  all  convenings  of  a  course  in  a  year. 


Annual  Training  Man-Day  Requirements  Number  of  man-days  per 
year  that  soldiers  will  be  rece Iving  a  course  of  instruction 
and  be  unavailable  for  assignment  to  other  duties. 

Attrition  Rate  The  rate  at  which  individuals  leave  the  Army 
at  each  paygrade  within  each  MOS. 

Audit  Trail  A  systematic  mechanism  for  tracking  development 
of  MPT  requirements  and  for  monitoring  changes  to  the  data, 
assumptions,  or  procedures  which  produce  the  MPT 
requirements. 

Availability  Ratio  An  estimate  of  availability  of  an  MOS  to 
support  a  Proposed  System. 

Base  Operations  Cost  Cost  to  the  base  operations  functional 
account  adjusted  by  the  total  number  of  training  man-weeks. 

Baseline  Comparison  System  (BCS)  A  current  operational 
system,  or  a  composite  of  current  operational  subsystems, 
which  most  closely  represents  the  design,  operational,  and 
support  characteristics  of  the  new  system  under  development 
(MIL-STD-1388-1A) . 

Basic  Combat  Training  (^T)  Fundamentals  of  basic  infantry 
combat  given  to  enlisted  Active  Army  and  Reserve  personnel 
without  prior  military  service  (AR  310-25). 

Basic  Noncommissioned  Officer  Course  (BNCOC)  A  course  that 
prepares  career  soldiers  in  Grade  E5  (Skill  Level  2)  for 
duties  at  grade  E6.  Performance-oriented  training  is 
stressed  (AR  351-1). 

Basic  Technical  Course  (BTC)  A  course  that  focuses  on 
training  critical  tasks  listed  in  the  Skill  Level  3 
Soldier's  Manual  for  a  given  MOS  (AR  351-1). 

Basis  of  Issue  Plan  (BOIP)  A  plan  which  indicates  the 
quantity  ot  new  or  modified  equipment  planned  for  each  type 
organization  and  the  planned  changes  to  personnel  and 
supporting  equipment  (AR  70-27). 


Bill  Payer  An  older  system  that  is  currently  consuming  MPT 
resources  and  that  will  be  phased  out  of  the  inventory  upon 
introduction  of  the  new  system. 


Career  Management  Field  (CMF)  A  list  of  operator  or 
maintainer  Military  Occupational  Specialties  for  one 
functional  branch  area. 

Class  Frequency  Average  number  of  times  a  Program  of 
Instruction  is  offered  each  year  (averaging  across 
locations) . 

Class  Length  Length  of  a  course  of  study,  usually  stated  in 
weeks. 

Comparability  Analysis  Process  by  which  estimates  of  the 
human  resource  requirements  of  an  emerging  weapon  system  are 
derived  from  the  known  requirements  of  similar  operational 
systems  and  subsystems. 

Comparable  Task  The  task  closest  to  a  new  task  in  terms  of 
task  criticality  and  similarity  to  type  or  class  of  task. 

Corrective  Maintenance  (CM)  All  actions  performed  as  a 
result  of  failure  to  restore  an  item  to  a  specific  condition 
(MIL-STD-1388-1A) . 

Cost  and  Training  Effectiveness  Analysis  (CTEA)  The  sole 
Army  process  used  to  assess  the  training  cost  and 
effectiveness  of  developing  weapon  systems. 

Course  Attrition  The  number  of  students  failing  to  graduate 
from  a  course  of  instruction. 

Course  Number  An  alphanumeric  code  used  to  designate  a 
Program  of  Instruction. 

Course  Module  A  component  instruction  which  teaches  a 
specific  task;  can  exist  at  course,  annex,  or  file  level. 

(1)  The  Advanced  Individual  Training 
ill  Identifier  (ASI)  courses  for  all 
MOSs  assigned  to  equipment  in  the  Predecessor,  Baseline 
Comparison,  and  Proposed  Systems;  and  (2)  the 
Noncommissioned  Officer  Education  System  (NCOES),  warrant 
and  commissioned  officer  courses  providing  direct 
instruction  on  system-specific  equipment. 

Crew  Maintenance  Maintenance  actions  that  are  performed  by 
the  personnel  whose  principal  duty  is  operation  of  a  system. 

Critical  Resources  The  implementation  or  management  risk 
associated  with  the  introduction  of  a  new  system.  This  risk 
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involves  manpower,  personnel,  and  training  demands  created 
by  the  new  system  compared  to  the  present  or  projected 
supply. 

Data  Management  Structure  A  systematic,  consistent  method  of 
organizing  information. 

Delta  The  Greek  letter;  symbolizes  an  expected  change  in  the 
manpower,  personnel,  and  training  requirements  cited  in 
output  reports. 

Dependency  The  relationship  (dependency)  between  a  specific 
maintenance  action  and  a  specific  metric.  For  example, 
maintenance  actions  associated  with  automotives  usually 
depend  on  the  number  of  miles  driven,  maintenance  associated 
with  an  artillery  tube  depends  on  rounds  fired,  and 
electronic  equipment  depends  on  hours  operated. 

Depot  Maintenance  Maintenance  involving  the  overhaul  of 
economically  repairable  materiel  to  augment  the  procurement 
program  in  satisfying  the  overall  Army  requirements  and  when 
required  to  provide  for  repair  of  materiel  beyond  the 
capability  of  general  support  maintenance  organizations  (AR 
310-25). 

Design  Differences  Differences  in  design  between  projected 
equipment  and  comparable  existing  equipment  used  in  the 
Baseline  Comparison  System. 

The  absence  of  a  detailed  design  at  the 
weapon  system's  development. 

Direct  Cost  Operational  and  Maintenance,  Army  (OMA) , 

Military  Personnel,  Army  (MPA)  and  Procurement  Account  (PA) 
cost  elements  that  are  directly  contributable  to  the  cost 
per  graduate  for  a  specific  course  or  group  of  courses.  The 
following  direct  costs  are  listed  in  TRADOC  Cost  Analysis 
Program  Reports  (MOS  Training  Costs),  ATRM-159  (Rl):  direct 
mission,  troop  support,  ammunition,  equipment  item 
depreciation,  student  pay  and  allowances,  travel  pay  to 
cours?,  per  diem  at  course. 

Direct  Maintenance  Effort  expended  by  maintenance  personnel 
in  the  actual  performance  of  maintenance  on  the  hardware  in 
accordance  with  the  prescribed  procedures  contained  in  the 
applicable  technical  manuals  (DA  PAM  700-127). 

Direct  Mission  Cost  Operational  and  Maintenance,  Army  (OMA) 
and  Military  Personnel  Army  (MPA)  cost  of  the  instructional 
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department's  costs,  plus  the  flying  hours  costs  plus  any 
other  costs  all  computed  on  a  per  graduate  basis. 

Algorithms  for  computing  these  costs  are  contained  in  Cost 
Analysis  Program  Reports  (MOS  Training  Costs)  ATRM-159  (Rl) 
docximents. 

Direct  Support  Maintenance  (PS)  Normally  authorized  and 
performed  by  designated  maintenance  activities  in  direct 
support  of  using  organizations.  This  category  of 
maintenance  is  limited  to  the  repair  of  end  items  or 
unserviceable  assemblies  in  support  of  using  organizations 
on  a  return  to  user  basis  (AR  310-25). 

Duty  Position  A  group  of  closely  related  tasks  and 
responsibilities  which  are  normally  assumed  by  one 
individual  (AR  310-25). 

End- I tern  Equipment  A  final  combination  of  end  item  products, 
components,  parts  and/or  materials  that  is  ready  for  its 
intended  use,  e.g.,  ship,  tank,  mobile  machine  shop, 
aircraft  (MIL-STD-1388-1A) . 

Engineering  Comparability  Analysis  A  structured  analytic 
process  utilizing  principles  oi  reliability/maintainability 
(R/M)  engineering,  logistics  engineering,  industrial 
engineering,  and  statistical  extrapolation  to  predict  the 
reliability  and  maintainability  of  new  systems  based  upon 
the  R/M  characteristics  of  existing  systems. 

• 

Environmental  Variables  Environmental  factors  such  as  heat, 
cold,  snow,  mud,  desert  conditions,  etc.,  which  may  impact 
the  operating  scenario  of  the  proposed  weapon  system. 

Equipment  Depreciation  Cost  Cost  of  equipment  dedicated  to  a 
course,  non-dedlcated  departmental  equipment,  and  school 
overhead  equipment  amortized  over  a  ten-year  period  and 
applied  to  Course  Cost. 

Equipment  Ident^icat ion  Code  (EIC)  An  alphanumeric  coding 
scheme  used  to  identify  specific  pieces  of  equipment.  May 
equate  to  Functional  Group  Codes,  Work  Unit  Codes,  or 
Logistic  Support  Analysis  Record  numbers. 

File  The  lessons  within  an  annex  of  a  program  of  instruction 
(POI )  in  which  tasks  are  taught. 


First  Unit  Equipped  (FUE)  The  first  troop  unit  to  be 
equipped  with  the  first  production  items/systems  (DA  PAM 
700-127) . 


Footprint  The  resources  of  an  earlier  system  within  which  a 
new  system  must  fit  or  closely  match. 


Fre<^uency  The  number  of  times  the  task  is  performed  per 
period  of  time. 

Front-End  Analysis  The  process  of  assessing  what  impacts  the 
manpower,  personnel,  and  training  requirements  of  an 
emerging  system  will  have  on  present  and  projected 
resources. 

Function  A  broad  category  of  activity  performed  by  a 
man-machine  system  (Draft  MIL-STD  on  Task  Analysis,  Feb. 
1980).  For  example,,  upper  level 'functions  of  a 
self-propelled  howitzer  would  be  to  shoot,  move,  and 
communicate.  The  requirement  to  shoot  would  have  lower 
level  functions  such  as  direct  and  indirect  fire. 

Functional  Allocation  The  categorization  of  th-*  activities 
(functions)  performed  by  a  man-machine  system*  into  who  or 
what  will  perform  them.  The  performance  categories  include 
hardware,  software,  human  (operator,  maintainer,  or 
support),  or  a  combination  of  these. 

Functional  Group  Code  (FGC)  A  standard  indexing  system  which 
parcels  the  weapon  system  into  its  functional  systems, 
subsystems,  components/assemblies,  and  parts. 

Functional  Hierarchy  Functional  structure  which  first 
identifies  the  ma]or  functions  and  subsequently  each  of  the 
lower  level  functions  a  system  is  expected  to  perform. 

These  functions  are  arranged  in  a  hierarchical  structure  to 
aid  in  the  identification  of  components  from  which  lower 
level  functions  and  their  sequence  are  determined  and 
described. 

Functional  Requirements  Functions  or  activities  required  of 
a  proposed  weapon  system.  These  required  functions  are 
developed  and  stated  in  DoD  and  Army  threat  studies,  mission 
area  analyses,  how-to-fight  manuals,  use  studies,  and  system 
concept  papers. 

General  Support  Maintenance  (GS)  The  maintenance  authorized 
and  performed  by  designated  Table  of  Organization  and 
Equipment  (TOE)  and  Table  of  Distribution  and  Allowance 
(TDA)  organizations  in  support  of  the  Army  Supply  System. 
Normally,  these  organizations  will  repair  or  overhaul 
materiel  to  required  maintenance  standards  in  a 


ready-to-issue  condition  based  upon  applicable  supported 
Army  area  supply  requirements  (AR  310-25). 

Generic  System  A  description  of  the  general  configuration  of 
equipment,  software,  and  duty  positions  required  to  fulfill 
all  system  functional  requirements  stated  in  Army  Mission 
Area  Analyses  and  System  Concept  Papers. 

Hardware  Function  An  activity  (function)  accomplished 
principally  by  the  equipment. 

High  Driver  A  system  element  which  consumes  a  large 
proportion  of  MPT  resources. 

Indirect  Cost  A  cost  which,  because  of  its  incurrence  for 
common  or  joint  objectives,  is  not  readily  subject  to 
treatment  as  a  direct  cost  (AR  310-25). 

Indirect  Maintenance  Also  stated  as  Indirect  Productive  Time 
(IPT);  the  time  required  for  normal  performance  of  the 
maintenance  tasks  but  that  does  not  in  and  by  itself  result 
in  the  total  time  required  to  accomplish  the  tasks. 

Indirect  maintenance  will  not  exceed  a  ratio  of  1  to  0.4 
(direct  to  indirect)  for  organizational  and  direct  support 
maintenance.  For  general  support,  indirect  maintenance  will 
not  exceed  a  ratio  of  1  to  0.22  (direct  to  indirect). 

Individual  and  Collective  Training  Plan  (ICTP)  The  primary 
resource  and  planning  document  for  developing  training 
subsystems  for  new  Army  systems.  The  ICTP  describes  the 
integration  of  training  subsystems  into  the  development  of 
the  total  system  as  well  as  integration  of  the  developing 
system  into  ongoing  training  programs. 

Individual  Work  Capacity  The  available  productive  man-hours 
(available  for  MOS  duties).  Excludes  all  non-available  time 
factors  such  as  security,  kitchen  patrol,  work  details, 
messing,  casualties,  personal  needs,  and  unit  movement  (AR 
570-2). 

Induced  Maintenance  See  Unscheduled  Maintenance,  Induced. 

Inherent  Maintenance  See  Unscheduled  Maintenance,  Inherent. 

Instructional  Department  Cost  Includes  Operations  and 
Maintenance,  Army  (OMA)  and  Military  Personnel,  Army  (MPA) 
costs  of  the  academic  department’s  cost  per  graduate.  It 
also  includes  pay  and  allowances  of  instructors  and  academic 
department  staff,  consumable  supplies  and  equipment,  and 


contractual  services.  The  method  used  to  compute 
Instructional  Department  Cost  can  be  found  in  the  Cost 
Analysis  Program  (MOS  Training  Costs)  documents  [ATRM-159 
(Rl)]- 

Instructional  Systems  Develoipment  A  systems  engineering 
approach  to  developing  a  training  program  based  on  task 
analysis.  ISD  includes  five  phases:  analyze,  design, 
develop,  implement,  and  control.  v 

Instructor  Contact  Hours  (ICH)  Instructor  manhours  required 
to  present  course  material  and  to  provide  assistance  to 
students  during  the  actual  presentation  of  course  of 
instruction  (DA  PAM  570-558). 

Intake  to  Payqrade  The  number  of  individuals  who  must  be 
assessed  or  promoted  into  a  paygrade. 

Line  Item  Number  A  number  identifying  the  position  which 
end-line  equipment  or  a  component  thereof  holds  in  the 
equipment  hierarchy. 

Logistic  Support  Analysis  An  analysis  supplied  during  the 
acquisition  process  in  order  to  insure  supportability  and 
other  Integrated  Logistic  Support  (ILS)  objectives.  The 
analysis  consists  of  iterative  definition,  synthesis, 
tradeoff,  and  test/evaluation  (MIL-STD-1388-1A) . 

Maintainability  A  system’s  or  its  component’s  requirement 
for  maintenance,  both  planned  and  corrective  determines  its 
maintainability.  Maintainability  is  a  product  of  the 
frequency  of  planned  maintenance  actions  and  corrective 
maintenance  actions  multiplied  by  the  time  these  actions 
take  to  complete. 

Maintenance,  Corrective  See  Corrective  Maintenance. 

Maintenance  Level  The  four  basic  levels  of  maintenance  into 
which  maintenance  activity  is  divided.  They  include 
organizational,  direct  support,  general  support,  and  depot 
(DA  PAM  700-127). 

Maintenance  Manhours  Per  Maintenance  Action  A  measure  of  the 
maintainability  parameter  related  to  item  demand  for 
maintenance  manpower:  the  sum  of  maintenance  man-hours 
divided  by  the  total  number  of  maintenance  actions 
(preventive  and  corrective)  during  a  stated  period  of  time 
(KIL-STD-721C). 


Maintenance,  Preventive  See  Preventive  Maintenance. 


Maintenance  Ratio  A  measure  of  the  total  maintenance 
manpower  burden  required  to  maintain  a  system.  It  is 
expressed  as  the  cumulative  number  of  manhours  of 
maintenance  expended  in  direct  labor  during  a  given  period 
of  time  divided  by  the  cumulative  number  of  end  items* 
operating  hours  during  the  same  time  (DA  PAM  700-127). 

Manpower  The  total  demand,  expressed  in  terms  of  the  number 
of  individuals,  associated  with  a  system. 

(MIL-STD-1388-iA) .  Includes  the  number  of  individuals  in 
each  MOS/ASI,  skill  level,  and  paygrade  required  to  operate 
and  maintain  a  system. 

Manpower  Losses  Per  Year  Losses  in  productive  manpower  at 
each  paygrade  in  an  MOS  due  to  promotion,  attrition,  and 
application  of  the  Transients,  Trainees,  Holdees,  and 
Students  (TTHS)  percentage  to  the  manpower  requirements  over 
the  course  of  a  year. 

Manpower  Requirements  An  emerging  weapon  system’s 
qualitative  and  quantitative  manning  needs. 

Manpower  Requirements  Criteria  (MARC)  The  manpower 
requirements  of  positions  for  Army  units  as  defined  in  AR 
570-2. 

Mean  Time  to  Repair  (MTTR)  A  basic  measure  of 
maintainability.  MTTR  is  calculated  by  summing  corrective 
maintenance  actions  times  for  a  particular  item  and*  dividing 
this  sum  by  the  total  number  of  failures  of  that  item  at  a 
specified  maintenance  level. 

Military  Occupational  Specialty  (MOS)  A  group  of  duty 
positions  that  require  closely  related  skills  such  that  a 
person  qualified  in  one  duty  position  in  an  MOS  can,  with 
adequate  on-the-job  training  (OJT),  perform  in  any  of  the 
other  positions  that  are  at  the  same  level  of  difficulty. 

Military  Occupational  Specialty  Code  (MOSC)  A  specific 
occupational  ident if icat ion  identifying  type  and  level  of 
skill,  level  of  proficiency,  and/or  scope  of  responsibility 
(AR  611-201);  stated  in  terms  of  MOS  and  skill  level. 

Military  Personnel,  Army  (MPA)  An  appropriation  that 
provides  for  pay,  allowances,  individual  clothing, 
subsistence,  interest  on  deposits,  gratuities,  permanent 
change  of  station  travel,  per  diem  portion  of  temporary  duty 
travel  between  permanent  duty  stations  for  members  of  the 


Army  on  active  duty  and  military  academy  cadets.  Also 
includes  expenses  of  apprehension  and  delivery  of  deserters, 
prisoners,  and  members  absent  without  leave  (AR  37-100-80). 


Mission  A  clear,  concise  statement  of  a  task  or  tasks  to  be 
accomplished. 

Mission  Area  A  broad  subdivsion  of  the  Army's  overall 
mission,  which  is  to  prepare  for,  engage  in,  and  win  land 
wars. 

Mission  Area  Analysis  Process  by  which  a  threat  is  analyzed 
and  a  counter  to  this  threat  (i.e.,  the  mission)  is 
postulated.  The  mission  is  stated  in  the  Mission  Area 
Analysis's  Studies  and  System  Concept  Papers. 

Characteristics  Threat  and  environment  impacts  define 
specific  mission  characteristics.  Frequently,  mission 
characteristics  require  specific  performance  requirements  of 
a  system. 

Mission  Name  Name  assigned  to  a  specific  mission  that  a 
system  is  expected  to  accomplish.  For  example.  Defeat  Enemy 
Armor  is  a  mission  that  could  be  assigned  to  armored  units, 
aviation  units,  and  infantry  equipped  with  anti-armor 
systems. 

Mode/Concept  Details  the  maintenance  concept,  organizational 
concept,  and  the  operational  mode/concept  proposed  for  a 
system.  Firing  40  rounds  per  hour,  moving  three  times  a 
day,  fixing  forward,  and  performing  all  organizational 
maintenance  actions  within  30  minutes  are  examples  of  modes 
and  concepts. 

New  Technologies  The  additional  technologies  (in  addition  to 
technologies  incorporated  in  current  systems)  that  a  system 
needs  to  meet  stated  performance  requirements. 

Normalized  Graduates  The  number  of  students  who 
satisfactorily  completed  the  course  (graduate),  as  adjusted 
for  carryovers.  Norm  grads  equal  the  number  of  actual  grads 
minus  one-half  the  number  of  students  in  training  in  the 
beginning  of  the  fiscal  year  plus  one-half  the  number  of 
students  in  training  at  the  end  of  the  fiscal  year. 

Number  of  Acquisitions  The  total  number  of  systems  to  be 
purchased.  Includes  TOE  as  well  as  systems  purchased  for 
Reserve  Forces  and  operational  floats.  Also  includes 
systems  purchased  to  be  pre-posit ioned  but  n>  t  manned. 


One-Station  Unit  Training  (OSUT)  Training  conducted  at  one 
location;  includes  both  basic  and  advanced  individual 
training  for  combat  arms  MOS  and  selected  combat  support 
MOS.  Training  is  conducted  in  one  unit  with  the  same  cadre 
and  one  program  of  instruction  (POI)  (AR  351-1  and  PM  25-1), 

Operat inq  Strength  The  present  and  absent  strength  of  an 
organization  classified  under  the  item  "personnel  status"  of 
the  morning  report  heading  as  "permanent  party".  Does  not 
include  "intransit"  strength  (AR  310-25). 

Operational  Environment  Characteristics  Environmental  and 
operational  factors  that  will  impact  the  operating  scenario 
of  the  proposed  weapon  system.  Includes  environmental 
variables  as  veil  as  operational  and  scenario  dependent 
variables  such  as  smoke,  NBC,  and  night  operations. 

Operational  Manning  (OM)  The  number  of  personnel  required  to 
operate  a  system  in  an  operational  environment. 

Operations  and  Maintenance,  Army  (OMA)  An  appropriation  that 
provides  for  the  operation  and  maintenance  of  all 
organizational  equipment  and  facilities  of  the  Army; 
procurement  or  requisite  equipment  and  supplies;  production 
of  audiovisual  instructional  materiel  and  training  devices; 
operation  of  service-wide  and  establishment-wide  activities; 
operation  of  depots,  schools,  training,  and  programs  related 
to  the  operation  and  maintenance  of  the  Army  (AR  37-100-80). 

Optimum  Class  Size  The  number  of  students  designated  for  a 
Class  which,  due  to  instructional  considerations,  is 
considered  optimum. 

Organizational  Maintenance  (ORG)  Maintenance  authorized  for 
ana  performed  by  a  using  organization  on  its  own  equipment 
(AR  310-25). 

Payqrade  (PGP)  The  statutory  paygrade  established  in  the 
Career  Compensation  Act  of  1949,  as  amended  (AR  310-25). 

Per  Diem  at  Course  The  students*  daily  expenses  vhic^  are 
costed  for  courses  that  are  less  than  twenty  weeks  in  length 
[ATRM-159  (Rl)l. 

Performance  Measure  The  qualitative  description  of  how  the 
function's  performance  will  be  assessed. 

Performance  Standard  An  established  number  of  man-hours 
needed  to  accomplish  a  unit  of  work  (AR  310-25). 


Period  Reported  The  period  of  time,  in  days,  that  the  system 
if?  to  maintain  continuous  operation  and  for  which  workload 
and  manpower  requirements  are  to  be  determined. 

Personnel  Flow  Rates  The  rates  of  progression  of  individuals 
through  the  military  personnel  system.  Includes  promotion, 
attrition,  and  TTHS  rates. 

Personnel  Pipeline  The  personnel  structure  that  must  be 
maintained  to  insure  that  required  manpower  requirements  are 
met. 

Personnel  Requirements  The  number  of  people  who  must  be 
carried  in  a  personnel  pipeline  to  satisfy  stated  manpower 
requirements.  This  number  must  also  offset  manpower  losses 
that  result  from  attrition,  advancement,  and 
non-availability. 

Perturbation  Value  A  quantitative  representation  of  the 
impact  of  the  design  differences  between  the  Baseline 
Comparison  System  and  the  Proposed  System, 

Phased  Schedule  A  schedule  that  lists  the  number  of  new 
systems  to  be  placed  in  service  per  year. 

Planned  or  Estimated  Schedule  The  planned  or  estimated 
schedule  for  a  new  system  progressing  through  the 
acquisition  process. 

Predecessor  System  An  Army  system  that  is  performing 
mission(s)  that  will  eventually  be  performed  by  the  new 
system. 

Prepositioned  Materiel  Configured  to  Unit  Sets  (POMCUS) 
Equipment  that  has  been  procured  but  is  held,  unmanned,  in 
readiness  for  future  use. 

Preventive  Maintenance  (PM)  All  actions  performed  in  order 
to  retain  an  item  in  specified  condition.  Involves 
systematic  inspection,  detection,  and  prevention  of 
incipient  failures  (MIL-STD-1388-1A) , 

Primary  Leadership  Course  (PLC)  A  leadership,  supervisory, 
and  management  course  built  around  the  environment  in  which 
combat  support /combat  service  support  leaders  perform  their 
duties  (AR  351-1) , 

Primary  Nonconunissioned  Officer  Course  (PNCOC)  A  non-MOS 
specific,  field-oriented  course  built  around  basic  soldier 


skills  and  tasks  that  prepares  £4  soldiers  for  duties  at  the 
E5  level  (AR  351-1). 

Primary  Technical  Course  (PTC)  A  course  that  focuses  on 
training  critical  tasks  listed  in  the  Skill  Level  2 
Soldier’s  Manual  for  a  given  MOS.  Training  is  provided  in 
resident  and  extension  modes. 

Procurement  Appropriation  (PA)  Five  continuing  (multi-year) 
appropriations  that  provide  funds  for  procurement, 
manufacture,  and  conversion  of  major  items  of  combat  and 
support  equipment,  including  ammunition,  aircraft,  missile 
systems,  weapons,  combat  and  support  vehicles. 

Program  of  Instruction  (POI)  The  training  management 
document  that  specifies  the  purpose,  prerequisites,  content, 
duration,  and  sequence  of  instruction  for  normal  resident 
and  non-resident  courses  (AR  310-25). 

Promotion  Rate  The  rate  at  which  individuals  advance  from 
one  paygrade  to  another. 

Proposed  System  An  analytic  construct  used  to  determine  the 
functional  requirements  of  a  new  system.  It  incorporates 
the  technological  advances  likely  to  exist  before  the 
system’s  projected  initial  operational  capability  date. 

^uasi-Program  of  Instruction  A  partial  program  of 
instruction  designed  to  evaluate  the  impact  of  emerging 
system  designs  on  existing  courses  of  instruction.  It  also 
helps  determine  requirements  for  new  courses  of  instruction. 

Reliability  Can  be  defined  as  (1)  the  duration  or 
probability  of  failure-free  performance  under  stated 
conditions,  or  (2)  the  probability  that  an  item  can  perform 
its  intended  function  for  a  specified  interval  under  stated 
conditions  (MIL-STD-1308-1A) . 

Reliability^  Availability,  Maintainability  (1^)  A  measure 
of  reliability  or  maintainability  that  includes  the  combined 
effects  of  item  design,  quality,  installation,  environment, 
operation,  maintenance,  and  repair  (AR  702-3). 

Replacement  Year  Year  when  the  predecessor  system  is 
scheduled  to  be  totally  replaced  by  the  new  system. 

Scope  See  Scope,  System. 

Scenario  A  brief  description  of  the  theater,  environment  and 
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threat  factors  that  are  likely  to  be  associated  with  the 
system  missions. 


Scenario  Usage  Rate  The  utilization  rate  that  is  the  planned 
or  actual  number  of  life  units  expended  or  missions 
attempted  during  a  stated  interval  of  time  (MIL-STD-721C) . 
Life  unit  is  the  duration  of  applicable  use,  i.e.,  operating 
hours,  cycles,  distance,  rounds  fired. 

Scheduled  Maintenance  Preventive  maintenance  performed  at 
prescribed  points  in  the  item’s  life  (MIL-STD-1388-1A) . 

Scheduled  Unit  Training  Training  of  an  entire  unit  that 
occurs  at  regularly  scneduled  times.  Unit  training  provides 
reinforcement  of  previous  , raining  as  well  as  new  training 
in  group  and  unit  tasks. 

Self-Study  Individual  study  by  which  the  soldier  learns  new 
skills  or  reinforces  skills  already  learned  (AR  350-1). 

Senior  Noncommissioned  Officer  Course  (SNCOC)  Senior  level 
training  that  prepares  soldiers  in  grades  £8  and  E9.  It 
consists  of  resident  and  extension  training  as  well  as 
on-the-job  experience  (AR  351-1). 

Sergeants  Major  Academy  (SGMA)  The  capstone  of  enlisted 
training.  Master  and  first  sergeants  (£-8)  are  prepared  for 
high-level  responsibilities  in  both  troop  and  senior  staff 
assignments  (AR  351-1). 

Service  School  Institutional  training,  either  individual  or 
collective,  conducted  in  Army  schools  or  Army  training 
centers;  uses  instructional  systems  development  materials. 

Skill  Level  (1)  Level  of  proficiency  required  for 
performance  of  a  specific  military  job,  (2)  the  level  of 
proficiency  at  which  an  individual  qualifies  in  that 
military  occupational  specialty  (AR  351-1). 

Student  Pay  and  Allowance  Cost  Weekly  rate  of  pay  for  the 
model  grade  of  a  student  based  upcn  the  Composite  Standard 
Rates  for  Existing  Military  Personnel  Services  (AR  37-108). 
This  weekly  rate  multiplied  by  the  course  length  in  weeks  is 
used  to  compute  cost  per  graduate  (ATRM-159  (Rl)]. 

Supervised  On-the-Job  Training  Structured  training 
accomplished  while  a  person  is  working  in  a  particular  skill 
level  and  MOS  (AR  351-1). 


Support  Cost  That  portion  of  total  indirect  cost  not 
included  in  base  operations  cost  per  graduate.  These  are 
installation  costs  that  include  training  aids,  base 
communications,  medical,  and  family  housing  on  a  pro-rate 
share  of  school's  military  man-years  (MMY)  supported  as  a 
percent  of  the  total  benefiting  tenant  MMY  [ATRM-159  (Rl)]. 

System  The  combination  of  people,  hardware,  and  information 
which,  when  interacting  as  a  whole,  is  capable  of  performing 
a  required  mission  on  the  battlefield. 

System  Functional  Requirement  The  attributes  or  capabilities 
required  to  be  present  in  the  system  elements  so  that  each 
element  and  the  system  as  a  whole  can  accomplished  assigned 
actions. 

System  Scope  A  precise  definition  of  the  range  and  depth  of 
a  weapon  system,  including  (1)  number  of  missions  assigned, 
(2)  number  of  materiel  commodities  incorporated,  and  (3) 
number  of  distinct  platforms  and/or  components  comprising 
the  system. 

System  Density  The  quantity  of  systems  requiring  maintenance 
and  supply  support  in  a  unit,  group  of  units,  or  at  a 
maintenance  level.  Stated  in  terms  of  the  Basis  of  Issue 
for  units. 

System  Performance  Goals  A  description  of  the  goals  that 
must  be  achieved  for  each  system  performance  measure. 

System  Performance  Measures  Measures  that  describe  the 
performance  capabilities  that  must  be  achieved  for  each 
system  function.  System  performance  measures  usually 
consist  of  speed,  rate  of  fire,  etc. 

Systems  Analysis  An  orderly  approach  to  helping  a  decision 
maker  choose  a  course  of  action.  Its  basis  is  a  model  or 
idealized  description  of  the  situation  under  analysis. 

Table  of  Organization  and  Equipment  (TOE)  A  table  that 
prescribes  the  normal  mlssfch,  organizational  structure, 
personnel,  and  equipment  requirements  for  a  military  unit. 

If  forms  the  basis  for  an  authorization  document  (AR 
310-25). 

Task  A  unit  of  work  activity  that  constitutes  a  logical  and 
necessary  step  in  the  performance  of  a  job/duty.  It  is  the 
smallest  unit  of  behavior  in  a  job  that  describes  the 
performance  of  a  meaningful  function  in  the  job  under 
cpnsi '  * 


Task  Description  Concise  wording,  usually  verb-object  form, 
that  describes  a  task. 

Task  Number  A  numerical  code  used  to  designate  a  task. 

Threat  Characteristics  The  specifics  of  an  enemy  threat  as 
determined  in  a  Threat  Analysis  and  stated  In  a  Threat  Study 
(see  also  Mission  Analysis  and  Mission  Characteristics). 

Threat  Variables  The  range  and  complexity  an  enemy  threat 
can  take.  Includes  the  consideration  given  in  a  Threat 
Analysis  to  the  compounding  of  threat  that  a  new  enemy 
capability  can  have  in  concert  with  other  new  or  existing 
threats.  Also  includes  consideration  of  current  weakness  in 
countering  the  new  and  combined  enemy  threat. 

Training  Aids  Cost  Cost  of  installation-support  training 
aids  adjusted  by  the  total  number  of  training  man-weeks. 

Training  Man-Days  The  length  of  class  time  needed  to  train 
an  individual  student  in  a  course. 

Training  Resource  Requirements  Analysis  (TRRA)  A  process 
used  to  estimate  systematically  the  training  requirements 
for  Army  weapon  systems  during  the  earliest  phases  of  their 
development.  These  requirement  estimates  include 
specification  of  the  system’s  task,  course,  and  resource 
requirements. 

The 
le 

and  are  therefore  unable  to  contribute  to  the  work 
associated  with  the  weapon  system. 

Travel  Pay  to  Course  The  travel  cost  per  graduate  computed 
on  a  standard  cost  per  mile.  The  cost  per  mile  is 
multiplied  by  a  class  average  one-way  mileage,  which  is 
obtained  from  a  sample  of  student  records. 

Type  of  Instruction  Type  of  instruction  used  for  a  training 
course.  Typical  categories  are  conference,  demonstration, 
practical  exercise,  e'lc.  (TRADOC  CIR  351-12). 

Those  maintenance  actions 
ng  an  item  to  a  specified 
condition  when  the  failure  has  been  caused  by  a  condition 
resulting  from  an  inherent  fault  in  design  or  strength  of 
material  specified. 


Unscheduled  Maintenance,  Inherent 
(or  events)  necessary  for  restori 


Transients,  Trainees,  Holdees,  and  Students  Rates  (TTHS) 
percentage  of  personnel  in  a  paygrade  who  are  unassignab 


Unscheduled  Maintenance,  Induced  Those  maintenance  actions 
(or  events)  necessary  for  restoring  an  item  to  a  specified 
condition  when  the  failure  has  been  induced  by  a  condition 
(including  environmental)  not  resulting  from  an  inherent 
fault  of  an  item. 

Unscheduled  Maintenance,  Other  Those  maintenance  actions  (or 
events)  necessary  for  restoring  an  item  to  a  specified 
condition  that  was  not  caused  directly  by  induced  or 
inherent  failures.  Causes  include  removal  to  gain  entry, 
cannot  duplicate  reported  descrepancy,  cannibalization, 
unscheduled  inspections,  etc. 

Workload  The  amount  of  work,  stated  in  predetermined  work 
units,  that  organizations  or  individuals  perform  or  are 
responsible  for  performing  (AR  310-25), 
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Logistic  Support  Analysis  Record 
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Mission  Area  Analysis 
Maintenance  Action/Allocation  Chart 
Materiel  Acquisition  Process 
Manpower  Requirements  Criteria 
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MCO 


Marine  Corps  Order 


MEEI 

MFP 

MIL-STD 

MILPERCEN 
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MMH/MA 
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MOSB 

MOSC 

MP/OMS 

MPA 

MPT 
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MRC 
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MTBF/MTBMA 

MTTR 
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Minimum  Essential  Elements  of 
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Materiel  Fielding  Plan 

Military  Standard 

Military  Personnel  Center 

Maintenance  Man-hours 

Maintenance  Man-hours  .Per 
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N 


NASA 


National  Aeronautics  and 
Space  Administration 


NATO 

NAVMMACLANT 

NAVEDTRA 
NAVPERS 
Navy  3M 
NBC 
NCOES 

NEC 

NEPDIS 

NET 

NETP 

NITRAS 

NMSO 

NODAC 

NOTAP 

NTEC 

NTP 

OiO 

OCS 

OM 


North  Atlantic  Treaty  Orgaiiizat ion 

Navy  Manpower  and  Materiel  Analysis 
Center,  Atlantic 

Naval  Education  and  Training 

Naval  Personnel 

Materiel  Maintenance  Management 

Nuclear,  Bacteriological,  Chemical 

Noncommissioned  Officer 
Educational  System 

Naval  Enlisted  Classification 

Navy  Enlisted  Professional  Development 
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New  Equipment  Training 
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Navy  Maintenance  Support  Office 

Navy  Occupational  Development  and 
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Navy  Occupational  Task  Analysis 
Program 

Naval  Training  Equipment  Center 

Navy  Training  Plans 
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Organizational  and  Operational  Plan 

Optimal  Class  Size 

Operational  Manning 


OMA 


ORSA 

OSUT 

OT 

Pam 

PERT 

PGD 

PIB 

PLDC 

POE 

POMCUS 

PM 

PM 

PM  TRADE 

PNCOC 

POE 

POI 

PQS 

PTC 

PV 


Operations  and  Maintenance,  Army 
Operations  Research/Systems  Analyst 
One  Station  Unit  Training 
Operational  Test 
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Pamphlet 

Program  Evaluation  Review  Technique 
Paygrade 

Program  Information  Brief 

Primary  Leadership  Development 
Course 

Projected  Operational  Environment 
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Preventive  Maintenance 
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QQPRI 


Quantitative  and  Qualitative  Personnel 
Requirements  Information 


Quasi -POI 

Quasi-Program  of  Instruction 

R 

R&M 

Reliability  and  Maintainability 

RAM 

Reliability,  Availability,  and 
Maintainability 

Reg 

Regulation 

ROC 

Required  Operational  Capability 

RPV 

R<.irtotely  Piloted  Vehicle 

S 


SAT 

Systems  Approach  to  Training 

SDC 

Sample  Data  Collection 

SEAD 

Suppression  of  Enemy  Air  Defense 

SGMA 

Sergeants  Major  Academy 

SINCGARS 

Single  Channel  Ground/Airborne 
Radio  System 

SME 

Subject-Matter  Expert 

SOJT 

Supervised  On-the-Job  Training 

SP 

Self  Paced 

SPH 

Self-Propelled  Howitzer 

SPT 

Support 

SQT 

Skill  Qualification  Test 

ssc 

Soldier  Support  Center 

SSG 

SSI 

SSPO 

STP 

SUBLANT 

SUBPAC 


Special  Study  Group 
Specialty  Skill  Identifier 
Strategic  Systems  Project  Office 
Soldier  Training  Publication 
Submarines  Atlantic 
Submarines  Pacific 


TAMMS 

TASC 

TASO 

TB 

TCA 

TD 

TDIS 

TDLR 

TDR 

TEA 

TFR 

TLR 

TM 

TOE 
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The  Army  Maintenance  Management  System 
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Technical  Bulletin 
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Training  Developer 

Training  Development  Information  System 
Training  Device  Letter  Requirement 
Training  Device  Requirement 
Training  Effectiveness  Analysis 
Trouble  Failure  Reports 
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Technical  Manual 
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Table  of  Organization  and  Equipment 

Tentative  Qualitative  and  Quantitative 
Personnel  Requirements  Information 
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TTHS 
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TSM 
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VHF-FM 
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WQEC 
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Ultra-High  Frequency 

US  Army  Manpower  Requirements  and 
Documentation  Agency 
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Work  Breakdown  Structure 
Weapons  Quality  Engineering  Center 
Work  Unit  Code 

Weapons  System  Acquisition  Process 
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